Breaking News
Opinion

Over the Internet of Things Hovers the Specter of Legacy Code

View Comments: Oldest First | Newest First | Threaded View
Page 1 / 2   >   >>
WKetel
User Rank
Rookie
legacy code and that "internet of things"
WKetel   8/10/2013 9:37:54 PM
NO RATINGS
The author has made a very valid point, which comes at the problem from a different point of view, but points at the same disaster, running out of memory and crashing to a halt. As Mr Anderson points out, memory is a big deal, and it is far from infinite. While I don't understand fully the differences between IPV4 and IPV6, his point about the memory problems is certainly valid enough to make one ask "is this really a good idea?" And the prospect of programs just continuing to allot memory space and then not release it does certainly describe a very real and very fatal fault in a lot of current code. And the description of the effort needed to make changes is sort of depressing, I think.

prabhakar_deosthali
User Rank
CEO
Can IPv4 and IPV6 co-exist in IOT
prabhakar_deosthali   8/11/2013 7:57:05 AM
NO RATINGS
This may turn out to be an another monster like the Y2K .

What we need is a well laid out plan for transition from IPV4 to IPV6 based networks without having to rewrite the code.

Could it be done by accepting the IPV4 addresses in a IPV6 network by padding the additional bits having a fixed pattern non-repetitive in the IPV6 address allocation.

 

This way we can retain the old code and the systems and they can particpate in the new IPV6 network.

May be I am oversimplifying the problem , but just a thought.

 

_hm
User Rank
CEO
Re: legacy code and that "internet of things"
_hm   8/11/2013 8:45:39 AM
NO RATINGS
This looks as opprotunity for more innovation. It may happen that all three approaches will be embraced - write new code for critical apps, device auto convert utilites for some predictable code and change code manually.

 

Kinnar
User Rank
CEO
Legacy Code and Modular/Layered Architecture
Kinnar   8/11/2013 11:17:40 AM
NO RATINGS
The threats and worries discussed in the article is worth discussing, but simultaneously we will have to allow ample amount room to the new developments and advancements, this is not the first time some modifications is happening in the internet era. The entire code is always getting modified by a globally community of the programmers. 

Also the Architecture of Network Protocol Suite is Modular and Layered so in someone is coming up with a perfectly running code at Network Layer, it will be getting accepted in all the variants of that particular OS.

Taichichuan
User Rank
Blogger
Re: Can IPv4 and IPV6 co-exist in IOT
Taichichuan   8/11/2013 11:04:28 PM
NO RATINGS
There are several transition techniques that already exist for bridgung from IPv4 to IPv6.  First, there is a way to encapulate an IPv4 address inside of an IPv6 address.  Additionally, there is a NAT 6-to-4 that allows for the use of IPv4 on one side and IPv6 on the other of a given router device. This is in addition to several tunneling techniques for encapulating packets of one type within the other.

Nonetheless, we will likely need to be able to support simultaneous v4 and v6 addressing in our applications for the next decade.  So, unlike a a Y2K where there was a single "drop-dead" date, the transition to v6 will be more of a battle of attrition. 

For networks that are completely closed, there's no need to convert other than to lessen long-term support costs.  For networks that have Internet access though, the need to support V6 will likely be more important as v6 adoption increases.

Taichichuan
User Rank
Blogger
Re: legacy code and that "internet of things"
Taichichuan   8/11/2013 11:19:18 PM
NO RATINGS
The use of all three techniques is more than likely what we'll be encountering in the next several years.  However, this will require that developers become aware of the new protocol and its different requirements/operation from that found in IPv4.  Fortunately, most of the differences can be found in the set-up and tear-down of the sockets.  Once they are configured, the actual sending and receiving of data across the sockets is identical between the protocols.

Where the use of IPv6 becomes more tricky is that the protocol itself is rather complex.  Router and neighbor discovery, the lack of a broadcast capability (IPv6 uses multicast heavily) and even just the size of the addresses will put a strain on systems with limited memory.  For example, you won't be finding an IPv6 stack that fits in 4K or even 64K of RAM like you can IPv4 implementations.  This means that processors like the venerable 8051 need not apply if IPv6 is included. 

Even with processors like the ARM Cortex M0/3/4, memory usage will be an important consideration.  This means that when it comes to IPv6, we will need to go back to an earlier time when saving bytes in an program implementation may be the difference between an application that fits versus one that doesn't.

LarryM99
User Rank
CEO
Good News / Bad News
LarryM99   8/12/2013 1:05:18 PM
NO RATINGS
The bad news is that a lot of legacy code will have to be rewritten. The good news is (also) that a lot of legacy code will have to be rewritten. If you look at modern versions of C/C++ and other languages mentioned in this article there have been tremendous advances in controlling memory leaks by default rather than depending on fastidious programmers to do so. The younger programmers in my group are much more comfortable with these new features, which is a good sign for the code quality of these rewrites in the future.

The real advantage is that we are now pretty much assuming that we are working with at least a 32-bit architecture. Trying to do this kind of code with a Z-80 or 6800 would be an exercise in futility. We are also generally working with megabytes of memory rather than kilobytes. One of the first systems I worked on back in the dark ages had 32 kbytes of RAM. The hardware engineer that I was working with made the comment that he couldn't imagine why anyone would need more than that. This was, of course, before Windows... :-)

Jack.L
User Rank
CEO
Fear Mongering?
Jack.L   8/12/2013 5:45:19 PM
NO RATINGS
This does strike me as a bit of fear mongering.

Memory leaks have and always will be an issue with programming. The fact that a memory leak can occur in an IPV6 implementation is just that an implementation detail and we have to ask is it any worse than any other memory leak that causes a crash? I do not think so. There will always be mistakes made.

 

As pointed out, there are ways to encapsulate IPV4 within subnetworks and one has to expect that much of the time, this is exactly what will happen. I do expect a lot of upgrading of routers and the like.

 

Most of the time, if a device is implemented with an 8051, etc. it will just not be feasible to "upgrade" the firmware to support IPV6. That said, how many internet enable 8051 powered devices a) Exist and b) Can be remote/field ugraded. To that end, talking about the issue is almost a non-starter in most cases. The device will either be encapsulated by the router or upgraded to newer hardware. No other solution will exist.

 

 

WKetel
User Rank
Rookie
Re: Fear Mongering?
WKetel   8/12/2013 10:08:50 PM
NO RATINGS
Jack, the problem that I see is that when there are huge amounts of memory available that bad code that constantly consumes memory will be aable to run for a long time before it crashes. The result will be that a lot of it will enter the real world public domain and be causing problems there. And unfortunately there is no mechanism in place to prevent this kind of problem.

 

Jack.L
User Rank
CEO
Re: Fear Mongering?
Jack.L   8/13/2013 3:32:39 PM
NO RATINGS
This is true, but the article makes it seem like memory leaks are a new issue and they are not. It is something we have been dealing with for literally decades. Good programming practices deal with it, bad ones do not. There is no doubt lots of bad code in the public domain with memory leaks, and lots without. The article (blog) practically implies its a done deal it going to happen all the time, and I do not think that is true.

Page 1 / 2   >   >>
Radio
NEXT UPCOMING BROADCAST
EE Times Senior Technical Editor Martin Rowe will interview EMC engineer Kenneth Wyatt.
Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Flash Poll