Hello,
I'm starting a project using the MOD5234 and would like some info on the limitations of the system's TCP capabilities. Specifically, I'm planning on using up to 50 MOD5234s accessing sensor data then communicating it back to a central MOD5234 server over TCP. I have used select() successfully in the past, but never with so many clients, and I have read that different architectures have different limitations on how many items can be in an fd_set.
If anyone has information on the following, I would greatly appreciate it:
1. How many items can the MOD5234 hold in a single fd_set?
2. Can a single MOD5234 TCP server handle 50 clients without significant performance degradation? (I realize this depends on the traffic coming through, but mostly I'm wondering about the overhead processing involved in keeping 50 TCP connections alive even if no data or minimal data is being sent)
3. I noticed a new development tools release that supposedly fixed several TCP bugs. Has anyone experienced any further problems with this build, or are there any known issues remaining with the TCP implementation? I don't want to design a system around TCP only to find that it's unreliable
Thanks very much,
David
MOD5234 TCP limitations?
Re: MOD5234 TCP limitations?
By default the TCP is set up for 32 Max active TCP connections.
Every listening socket counts as one.
If you are not using SSL, SSH, FilePost,UDP sockets (our UDP class uses no sockets) or other users of FD extra you can increase this to
55 or so....
Here is a cut and paste from a support response on this topic...
You can presently have 32 TCP connections or listening sockets.
If you want to have more of these...then you can change a constant
Its presently set to 32, there are 64 Fd's availible.
Presently 5 are for stdio and the first two serial ports.
32 are for TCP.
The balance (27) are used as extras.
The extras are used for
Any serial ports beyond the first two,
ie third or any of the 5234 TPU serial Ports, or PK70 quad serial boards.
UDP sockets,
internal timing in the tcp to serial factory apps.
File post when sending multiple part forms to HTTP pages.
SSH or SSL connections.
So if you are not using any of the above then then you can use all the
extras for TCP.
Do this by adjusting the constant:
TCP_SOCKET_STRUCTS in nburn\include\constants.h
After adjusting this constant you must recompile everything.
system, platform and your application.
Every listening socket counts as one.
If you are not using SSL, SSH, FilePost,UDP sockets (our UDP class uses no sockets) or other users of FD extra you can increase this to
55 or so....
Here is a cut and paste from a support response on this topic...
You can presently have 32 TCP connections or listening sockets.
If you want to have more of these...then you can change a constant
Its presently set to 32, there are 64 Fd's availible.
Presently 5 are for stdio and the first two serial ports.
32 are for TCP.
The balance (27) are used as extras.
The extras are used for
Any serial ports beyond the first two,
ie third or any of the 5234 TPU serial Ports, or PK70 quad serial boards.
UDP sockets,
internal timing in the tcp to serial factory apps.
File post when sending multiple part forms to HTTP pages.
SSH or SSL connections.
So if you are not using any of the above then then you can use all the
extras for TCP.
Do this by adjusting the constant:
TCP_SOCKET_STRUCTS in nburn\include\constants.h
After adjusting this constant you must recompile everything.
system, platform and your application.
Re: MOD5234 TCP limitations?
I once did a project with 24 MOD5272 NetBurners (they were all clients), but I was mostly interested in overall throughput. I know you didn't express an interest in that (yet) but the budget included a 24 board testing prototype just to mitigate risk. We found it extremely valuable in arriving at a final working solution.