11 replies to this topic

[mrgadget]

Hi, So finally after having my N+ sitting around for a few months I found some time to play with it. Very cool. But I have an issue with concurrent sockets. When ordering it, I did some googling and found a few sites/threads saying that wiznet had a limitation of 4 sockets, but the Plus doesn't use that so isn't subject to that limitation... So, I write essentially a TCP concentrator app (multiple devices talk to the netduino, which in turn talks to multiple (other) devices (these only allowing a single connection, hence the requirement). Imagine my surprise when I can only get 4 clients connected to it - then I go and try to make an outbound connection from it, and it closes one of the connected clients to make the outbound connection! Is it a problem with System.Net.Sockets.Socket? I have coded the app to allow 5 simultaneous inbound devices, and 10 outbound connections (15 total), but can never get more than 4. Any ideas?

[mrgadget]

Further to this - each socket is on it's own thread too - so is that perhaps the limitaion? Is there a thread count max? Cheers, Ben.

[mrgadget]

No-one? I'd really like to nail this one... Cheers, Ben.

[Dan T]

Sorry for the silence... but I just ran across this in file Opt.h in the N+ source code: /** * MEMP_NUM_TCP_PCB: the number of simulatenously active TCP connections. * (requires the LWIP_TCP option) */ #ifndef MEMP_NUM_TCP_PCB //#define MEMP_NUM_TCP_PCB 16 #define MEMP_NUM_TCP_PCB 5 #endif Seems relevant. Hope it helps.

[mrgadget]

Hi Dan Thanks for the reply. That does indeed look relevant - so is that a limitation of 5 connections restricted by current netduino firmware? Do I have any options here or do I have to look at a different board? Cheers, Ben.

[Dan T]

Yes. It looks like the restriction is 5 simultaneous connections in V4.2 RC3. It might have been 16 in some earlier build.

I do not know if you have any options. I'm still a newb on most of this stuff.

The following is pure speculation:
The Opt.h file is part of the networking code. I found it in
..\SourceCode_Netduino_AllEditions_4.2.0.0_RC3\DeviceCode\pal\lwip\lwip_1_3_2\src\include\lwip

It is full of similar variables whose value has been reduced. My guess is this was done to reduce the memory footprint of the lwip stack. (N+ is a bit memory starved.) If you were so inclined, you could try changing the value and recompiling your own custom firmware. This is NOT a task for a beginner - and I've have not tried it... but the hotshots talk about it like it's simple enough. Here are the not-too-detailed instructions that came with the Netduino source code download:

To build the Netduino Firmware v4.2.0 (release candidate 3):

1. Install the .NET Micro Framework 4.2 RTM Platform Kit
2. Copy these files over the Platform Kit (typically into C:\MicroFrameworkPK_v4_2)
3. Compile the desired Netduino solution

Good luck. Let us know what you learn, good or bad.

[Chris Walker]

Hi mrgadget, Sorry that I didn't see this thread earlier... Threads are very lightweight in .NET MF. You can have lots of them--but they each require a bit of RAM and of course some clock cycles. Generally speaking, make as many as you'd like. Chris

[mrgadget]

Hi Chris, Thanks for the response. Unfortunately threads aren't my issue. My issue with the the 5-socket networking limitation which appears to be a firmware limitation that's been introduced. I'll look at what's involved in compiling my own firmware, if that will indeed fix my issue - would simply changing that in the source code allow multiple connections? Cheers, Ben.

[Chris Walker]

Hi Ben, Yes, you can certainly change that constant and recompile (although the free GCC compiler tends to create larger firmware). That should increase the simultaneous number of connections. [Dan...these are the same settings used in the .NET MF 4.1 firmware; the 16 is commented out because that was the default setting before memory tuning.]. Chris

[Valkyrie-MT]

My issue with the the 5-socket networking limitation which appears to be a firmware limitation that's been introduced.

Wow, what a coincidence. I was just debugging why my UDP based set-time function worked on startup, but then not subsequently. It would crash on the new socket constructor. Strange. Then, I disabled another part of my code that happens to open a socket listener and the set-time started working again. I had just read this thread and immediately thought... I am running out of sockets! By my count, I had been using 3 UDP and 1 TCP. So I made the change suggested by Dan T, but it didn't work, although I don't know why not. Then I opened the Network_defines_lwip.h file and bumped up the TCP and UDP sockets and EUREKA! It works. I agree that the 5 is a bit too contrained. Maybe 10 would be a better number. Here is how I changed the file... (notice thechange from "min" -> "default")

#ifdef NETWORK_MEMORY_PROFILE_LWIP__small
    #define PLATFORM_DEPENDENT__MEM_SIZE                        MEM_SIZE__min
    #define PLATFORM_DEPENDENT__MEMP_NUM_PBUF                   MEMP_NUM_PBUF__min
    #define PLATFORM_DEPENDENT__MEMP_NUM_UDP_PCB                MEMP_NUM_UDP_PCB__default
    #define PLATFORM_DEPENDENT__MEMP_NUM_TCP_PCB                MEMP_NUM_TCP_PCB__default
    #define PLATFORM_DEPENDENT__MEMP_NUM_TCP_PCB_LISTEN         MEMP_NUM_TCP_PCB_LISTEN__min
    #define PLATFORM_DEPENDENT__MEMP_NUM_TCP_SEG                MEMP_NUM_TCP_SEG__min
    #define PLATFORM_DEPENDENT__MEMP_NUM_SYS_TIMEOUT            MEMP_NUM_SYS_TIMEOUT__min
    #define PLATFORM_DEPENDENT__MEMP_NUM_NETBUF                 MEMP_NUM_NETBUF__min
    #define PLATFORM_DEPENDENT__MEMP_NUM_NETCONN                MEMP_NUM_NETCONN__min
    #define PLATFORM_DEPENDENT__PBUF_POOL_SIZE                  PBUF_POOL_SIZE__min
    #define PLATFORM_DEPENDENT__PBUF_POOL_BUFSIZE               PBUF_POOL_BUFSIZE__min
    #define PLATFORM_DEPENDENT__TCP_MSS                         TCP_MSS__min
    #define PLATFORM_DEPENDENT__TCP_SND_BUF                     TCP_SND_BUF__min
    #define PLATFORM_DEPENDENT__TCP_SND_QUEUELEN                TCP_SND_QUEUELEN__min
    #define PLATFORM_DEPENDENT__TCP_WND                         TCP_WND__min
    #define PLATFORM_DEPENDENT__TCP_SNDLOWAT                    TCP_SNDLOWAT__min
#endif

Anyway, that worked. Getting everything setup to build firmware is a real hassle, but there is enough info in this forum to put the pieces together.

Chris -- I would really love to see this limit get a little bump up in the release...

-Valkyrie-MT

[mrgadget]

Valkyrie-MT, thats great news you got it to work - gives me a known end-point to work to! Did you have to make Dan's change as well as yours? Your code doesn't show a count (just 'default'), how many did you end up with? Cheers, Ben.

[Valkyrie-MT]

...how many did you end up with?

No, I did not make Dan's change. Just the one I mentioned.

From the config file:

/* MEMP_NUM_UDP_PCB: the number of UDP protocol control blocks. One per active UDP "connection". */
#define MEMP_NUM_UDP_PCB__min               4
#define MEMP_NUM_UDP_PCB__default           8
#define MEMP_NUM_UDP_PCB__max               16

/* MEMP_NUM_TCP_PCB: the number of simulatenously active TCP connections. */
#define MEMP_NUM_TCP_PCB__min               5
#define MEMP_NUM_TCP_PCB__default           16
#define MEMP_NUM_TCP_PCB__max               32

As you can see, UDP went from 4 to 8 and TCP went from 5 to 16.

Oddly, I still don't know how I ended up running out... I should have had just enough for what I was doing. But with these settings, I have more breathing room... Also, this may help my rudimentary web server queue up the incoming requests... I will have to test that.

Ultimately, RC3 is a HUGE improvement over RC2 which hung on the constructor. Now with RC3, we get an exception we can handle!

-Valkyrie-MT