NetBurner Community Forum

I've got an application where I need to open a lot of Telnet sessions. The Netburner is a Telnet client opening sessions to different devices that are Telnet Servers.

I've found I can open and maintain 24 connections without an issue but as I get close to 32 I start having issues as I would expect based off other forum postings I've read.

So my questions are, how many TCP connections do I need to reserve for the Netburner to use for web, debug, anything else the system would normally need, etc?

What are the max # of TCP connections the NB can support?

Can I raise increase them and what are the consequences of such?

I found the following in constants.h but wasn't quite sure to make of what the "OFFSET" does. I also was inferring I needed to reserve either 3, 5, or 8 TCP connections for webserver?

#define MAX_HTTP_PENDING_SOCKETS (5) // Number of sockets allowed to be pending on listening socket, performance will degrade < 3
#define MAX_HTTP_CONNECTED_SOCKETS (3) // Number of sockets allowed to be connected to http server simultaneously

#define SERIAL_SOCKET_OFFSET (3)
#define TCP_SOCKET_OFFSET (5)
#define TCP_SOCKET_STRUCTS (32)

Thanks.
Scott

Hi Scott,

I can't fully answer your question, but I have seen the following description in the file descriptor section of the programmers guide:

A file descriptor is a handle to a network socket, serial port or other system peripheral. May of the API functions pass a file descriptor to your application functions, such as the web server MyGet function example in this guide.

There are a maximum of 64 file descriptors:
0 – 2 for stdin, stdout and stderr
3 – 4 for the first two UART serial ports, 0 and 1.
5 – 36 for TCP (32 in total)
37 – 63 for expansion (additional UARTs, TCP sockets, or custom)

The expansion file descriptor positions can be used for many things, including additional serial ports, such as an external UART, or TCP ports.

So the offsets make sense for starting tcp sockets above stdio and the 2 uarts. Since a 54415 has 9 serial ports, some of the expansion fds must be used for those, but maybe that's optional. There are two functions I used to debug a tcp problem in which I was running out of sockets and buffers,
GetFreeSocketCount // free sockets
GetFreeCount // free buffers

There are also some I have seen, but not used, that work only in debug builds and provide the state of each socket.

You could run a test app and call those to see what your system is using. If you use the web server, you will need one socket for the listen, plus whatever you set those #defines to be, but I don't know if they are reserved or not, hopefully part of the socket pool so the system can react to where the load is at any given time. Would be interesting to know if a fd is reserved for all possible serial ports, or if a serial port fd is consumed only if the OpenSerial call initializes it.

You mention you can do 24 with no issues, but have a problem closer to 32. What exactly happens between 24 and 32? In a situation like this you might need to add some socket timeouts and/or overrides to handle error conditions like the clients crashing, not closing properly, leaving half open sockets, etc. I have done this with a data counter so that if no data is sent/received in x number of seconds, the socket is closed, or put on an inactive list so that if a new socket is needed, and there are not any available, a socket on the inactive list is closed and used for the new connection.

Chrome (and other browsers) opens 8 sockets when connecting to web servers. This will be where the instability starts above 24 active connections.

You start with 32 TCP sockets.

Are you running a webserver?
If so reserve 9 for that (1 listening socket, 8 connections from chrome)
If you are also running HTTPS then reserve 1 more.
If you have other listenign sockets (Telnet command, customer listen calls etc 1 each.)

Now subtract that from 32.
That is how many outbound tcp conenctions you can reliably make.


There are some extra FD_s that can be re purposed to be tcp connections.
Start with 26 extras.
Subtract 1 extra for every serial port other than 0,1 you are using.
Subtract 8 extras if you are running https.
Subtract 1 for each UDP socket (not udp class, but udpsockets)
Subtract one for ever case in your own code where you call GetExtraFd
SSH and WIFI may use some extras, I don't off the top of my head know how many, if you are using SSH or wifi ask and I'll get a correct answer.

This should tell you how many unused extra FD's you have.

Suppose after the calcs above you end up with 10 extras...
Then in constants.h make the following change...

Change
#define TCP_SOCKET_STRUCTS (32)

to

#define TCP_SOCKET_STRUCTS (32+10)

You now have 42 total TCP sockets.

In your description HTTPS gets 1 subtracted from the original 32, and 8 from the extra descriptors. Just want to verify that is correct. It seems like a lot:

From the original 32:
9 for the web server
1 for HTTPS

From the extra:
8 for HTTPS

So for the web server it is 10 + 8 = 18 if HTTPS is used?

Thanks guys, this discussion was all VERY informative!

For HTTP on a modern browser you need one tcp socket to listen...

and the browser may open 8 simultaneous connections so that is a total of 9....

For HTTPS you need to add one more listening socket (IE listening on both http and https ports)

Then you may need to support 8 simultaneous SSL browser connections via https. (Curse you chrome)


Now for each SSL (ie HTTPS) connection we need two fd's.
One normal TCP FD that represents the TCP connection that carries encrypted data out over the network.....
and one extra_Fd, this is the connection between the SSL subsystem and user application (or the web server) and caries the plain text data internally in the netburner.

Long term we plan to add the capability for additional TCP and extra FD sockets up to 100's. I'd be interested in how important this is for every one?

Long term we plan to add the capability for additional TCP and extra FD sockets up to 100's. I'd be interested in how important this is for every one?

This would be HUGE for me!! I'm getting into scenarios here where I need to be able to maintain numerous active TCP connections. In the application I'm doing right now 24 active Telnet client sessions is on the low end of what I need but will suffice for this immediate project...and I still have the 9 UART fd's in play too. Not to mention I've got multiple UDP ports open listening for traffic too but those don't appear to be sucking up the socket resources that I can tell.

In the future I can see scenarios where I may need to keep over a 100 TCP connections open. Low traffic levels, but I need the connections active and health checked.

Thanks.
Scott

Right now when a TCP packet comes in it does an extensive search for which socket goes with what packet.
Increasing the number of sockets in the system would be fairly simple, but it would have a performance hit as the average search for a socket got out of control.
A while ago I had the idea that the sequence number is a random value we choose at the start of the connection....
If we encode the socket number in that then we can actually improve the performance for larger numbers of sockets and add more....

The problem is that we have recently added a bunch of features to the beta build that are still really beta, IPV6 TLS etc...
I really don't want to add more features/changes in the library until these are stable or we won't be able to diagnose all the issues.

Part of the change to IPV6 was to convert everything to C++, with that change one could also give you access to the TCP objects themselves directly raqther than through an FD,this would allow tcp sockets outside the FD environment that might be of use to people as well.... This stuff is in the pipeline, but its not ready and putting it in right now will be detrimental to stability... we are kind of at our point of allowable maximum change until we get things sorted out with the IPV6 release.


Paul

I totally understand not wanting to destabilize this release. It's not something that is blocking me at the moment but in 6 months or more from now I will definitely be needing it more I'd say so I'd love to see it on the roadmap for the following release.

Thanks.
Scott