TCP/IP on embedded devices is not robust enough to act as webservers or other server type setups. This is a limitation of their connectivity. Anything IoT CAN NOT be reliably used as a server.
Its taken me 5 years to come to this realization. Hope it helps someone else.
I’m curious as to what lead you to this conclusion.
Experience.
Which is exactly the same thing that tells me to ignore vague posts such as this… I’m sorry, but this isn’t helpful in any way.
ditto (to @ Ianlee)
Ditto to which?
The word server can mean a million thing. A WiFi light bulb can have a server and Google has a server.
Server - able to manage and serve TCP/IP requests to more than 1 client at a time.
If I need a server, I’ll fire one up in Azure. I don’t want my light bulbs to have servers. That’s what gateways are for.
I use G120 as an embedded device in an industrial environment, and I always use it as an TCP server and TCP client and FTP server, and and and all at the same time in parallel.
These things run and run and run.
So far I have not a single complain about that the device would not be reliable.
The devices run 24/7, no regular reset.
Production runs about 16/6 in most, and 24/6 in some plants.
Well, I had some issues in cancelling outdated sessions once, then I got an OutOfMemoryException. But this was when around 6 or 7 times the normal number of parallel task were started.
So I guess it depends on the use case and a lot on robust programming skills (no offence intended here).
@ Reinhard Ostermeier - None taken.
Reinhard Ostermeier, hit the nail on the head. "at the same time in parallel"
Honestly, the only time I ever ran into what it seems like you are talking about is when i was locked into using a non RTOS environment, where I was unable to spin off new connections as background task. In a nut shell if you have a device that is able to accept a connection, and your using a RTOS then I cannot see any reason (other than ram, flash & speed) that would hold you back from many connections at the same time.
Sounds like you got frustrated, don’t give up! I haven’t run into a IoT device yet that I ran into this. Keep at it…
NOTE: if your using arduino, then I could see that being a bit of a PITA. But if its GHI’s stuff, you will be fine.
Encouragement from an unlikely source. It’s been 5 years of work; and I’ve grown tired.
More correctly, the TCP/IP stack in NETMF 4.3 is unreliable. It’s not “embedded devices” that are the problem, it’s the implementation of the TCP/IP stack in NETMF 4.3. They’re working on that for 4.4.
So it’s the stack then. I wonder what the problem is.
@ godefroi - while we all agree a improvement is needed, there are commercial products that use networking and netmf today.
Just something to keep in mind.
If you mean NETMF devices with “embedded devices”, then you may be right (hopefully only until 4.4 is out).
But as a more general statement, I don’t agree at all. Often it is quite natural to treat an embedded device as a server. And very often even as both a client and a server.
@ Cuno - I’ve been informed that Windows 10 on intel edision isn’t intended to be a server. This threw me for a loop. Now considering that business servers have ECC memory and embedded devices don’t, I think the problem is the definition of a server. How can you be reliable or fault tolerant with no ECC?
@ andre.m - ECC is the basics; it’s the foundation.
unless the hardware can recognize an ecc fault, reconfigure memory, and recover the transaction in progress, ecc means nothing.
very few servers, of any size, have this capability.