Multiple Sockets on Port 80

TCP/IP Chip W5500
1

I am running a web server on the W5500. I open two sockets for port 80 and poll the status looking for session established and deal with the incoming data.

If I try to have two clients connect at the same time I do see both sockets get used sometimes but I usually get one session unable to connect. Do I need to be polling more quickly? Is there a limit on how many sessions the wiznet will allow on the same port?

2

Hello Bill, I am not a developer of the chip, but if I would be a developer, I would assume connect request from remote host with different IP address and/or different source port making round robin between sockets.

Polling has nothing to do with it. When you poll you just get status of the socket. If socket does not connect it is not because you do not read its status, it is because connection is refused or times out much earlier than you get to socket CONNECT state. If you poll “not so fast” then remote network device will be “hanging” until your W5500’s driver understands that there’s connect and starts processing socket TX and RX data.

I assume that you instruct both sockets with LISTEN command initially, and then when one finishes the session you reopen socket and re-instruct it to LISTEN. If socket is not in listening state, remote device’s connection request will time out.

3

[quote]Polling has nothing to do with it. When you poll you just get status of the socket. If socket does not connect it is not because you do not read its status, it is because connection is refused or times out much earlier than you get to socket CONNECT state. If you poll “not so fast” then remote network device will be “hanging” until your W5500’s driver understands that there’s connect and starts processing socket TX and RX data.

I assume that you instruct both sockets with LISTEN command initially, and then when one finishes the session you reopen socket and re-instruct it to LISTEN. If socket is not in listening state, remote device’s connection request will time out.[/quote]

Thanks Eugeny - that’s what I expected too but it’s not what I see. I may have to set up a smaller scale, more controlled, experiment so I can be sure of the states of the sockets when i try the connection.

4

Hi,
I noticed that until now only speak about connection.
In reality you should explain how once you get a connection attempt you solve the answer.
The request / response cycle in HTTP should be the fastest as possible.
Are you sure you process the request properly?
Wait until OK + CRLF before you start to answer and then close the connection?
Still check the connection status between connect and before answering?
I think you have problems purely due to the protocol, probably some times begins the answer but in reality you’ve already lost the socket.