TCP Sockets Connection Limit?

I create a server socket in FEZ Cerberus, and also create a client socket in PC (window xp). It seems have a limit in connections. There are only five connections I can make.

When I create the sixth connection, the server has no response. I also try it in mountaineer mainboard and the same. Is there limit in connections ?

        public void Start()

            server = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
            IPEndPoint localEndPoint = new IPEndPoint(IPAddress.Any, 80);
            new Thread(StartServerInternal).Start();

        private void StartServerInternal()

            while (true)
                // Wait for a client to connect.
                    Debug.Print("wait client... " + i.ToString());
                    Socket clientSocket = server.Accept();
                    Debug.Print("Get client... " + i.ToString());
                    // Process the client request.  true means asynchronous.
                    new ProcessClientRequest(clientSocket, true, i);
                catch (SocketException e)
                    Debug.Print("Exception" + e.ToString());

Yes there is due to limited ram. I know it is 128 on G120 but not sure about Cerberus. 8 or less sounds about right.

How quickly do the connections close? I’m running into a problem where the ENC28 connected to a Cerberus stops responding for awhile, then starts again. I only have one browser connecting and I am not hitting refresh very fast, maybe once every 10 seconds. Sometimes I will get 1 response before it stops, other times it will work a whole bunch of times before it stops responding.

Code below if it matters.

        private static Gadgeteer.Modules.IanLee.IO60P16.IO60P16Module io60p16;

        void ProgramStarted()
            Networking.Adapter.Start(new byte[] { 0x5c, 0x86, 0x4a, 0x00, 0x00, 0xde }, "mip", Networking.InterfaceProfile.Cerberus_Socket6_ENC28);
            Networking.Adapter.OnHttpReceivedPacketEvent += new Networking.Adapter.HttpPacketReceivedEventHandler(Adapter_OnHttpReceivedPacketEvent);
            Networking.Adapter.ListenToPort(80);  // Listen on Port 80, the default web server port

        static void Adapter_OnHttpReceivedPacketEvent(Networking.HttpRequest request)
            System.Text.StringBuilder xml = new System.Text.StringBuilder();
            xml.AppendLine(@ "<?xml version=""1.0"" encoding=""UTF-8"" standalone=""yes""?>");
            xml.AppendLine(@ "<dios time=""" + DateTime.Now.ToString("MM/dd/yyyy hh:mm:ss") + @ """>");
            for (int port = 0; port < 8; port++)
                for (int pin = 0; pin < 8; pin++)
                    xml.AppendLine(@ "  <dio port=""" + port.ToString() + @ """ pin=""" + pin.ToString() + @ """ value=""" + io60p16.Read((GTM.IanLee.IO60P16.IOPin)(byte)(port * 16 + pin)).ToString() + @ """ />");
            xml.AppendLine(@ "</dios>");
            byte[] webPage = System.Text.Encoding.UTF8.GetBytes(xml.ToString());
            var s = new System.IO.MemoryStream(webPage);
            Networking.HttpResponse resp = new Networking.HttpResponse(s);
            resp.ContentType = "text/xml";

Actually they linger. There was a way to disable this in 4.1. Not sure how on the new stack.

So with the low limit on connection count, any way to improve this behavior? Or any way to specifically state that a response is done?

Here you go:

Look for SocketOptionName.DontLinger

Make sure you set the option after binding…

This was the kind of stuff I hoped to avoid by purchasing pre-built modules and using provided drivers. Well, at least it’s still .NET.

Things like this help remind me just how spoiled some of us .NET developers get by so much stuff just working most of the time, unlike the other languages where you have to do every little piece yourself.

Just in case anyone wants what is probably a bad solution when using mIP, inside of the packet handler I added the following as the last 2 lines of code:


I’m sure it is bad for some reason, but it seems to be clearing the connections and letting me move on.

@ Gus - Thanks.