Your fear is not justified. I am looking for help. I was hoping you would respond. I would like your input on a socket function.
Then I will ask you to do three things for me please;
+ Read my comments completely.
+ Try not to ignore what you might not understand.
+ Ask about what you might not understand.
I believe this is due to the socket failing to stop listening for a new client, and accepts the next connection before my code sends a response to the previous connection.
Fantastic, we have some common ground. As I said some time ago, Socket states are mutually exclusive. A Socket can not be in both the Established and Listening states at the same time. Your experiments are showing you what happens when that rule is broken.
If you might understand the implications of the network being asynchronous. You might understand the H&D chip and the AT32 MCU firmware on the shield handle the protocol independently of your sketch. I will post some test code which categorically proves that is what happens.
Then you will get the wrong file (previous client request) on the current connection.
You need to straighten out your understanding of the relationship between;
+ TCP - A Session layer [u]protocol[/u]
+ Sockets - An application layer [u]interface[/u]
A Socket can only behave like a Socket, when it follows the rules of the protocol it is manipulating. The interface must send SYN, FIN, ACK, RST packets in the right order at the session layer, to keep endpoints separated at the application layer. BTW, a TCP end point is the unique combination of Source IP and [u]Source[/u] Port number.
The wifi shield has 4 sockets. Each has its own section of memory to handle that socket. Each will handle one client connection at a time.
For the sake of clarity, can we put aside how many Socket instances the Shield firmware may or may not provide. We only need to concern ourselves with the one instance which is providing the broken Server functionality, for the minute.
I see the problem now as the one socket used by the server never stops listening for a new connection.
Yes. A Socket can not be both Listening and Established. I keep repeating this because it is really, really important.
It seems it accepts a new connection once my code empties that socket's rx buffer of the client request.
TCP connections are accepted by the H&D chip and data is placed into the Rx buffer by the AT32 firmware, independently of your sketch polling the SPI bus. See the test code below.
The ethernet shield does not have this problem because it will use all 4 sockets for server functions. When a client is detected on a socket, that socket quits listening, and a new server socket starts listening if one is available.
When a Socket in the Listening state is assigned to an end point, it changes to the Established state. A Socket can not be in two states at once. Note, I am capitalising Socket because I am talking about a standard Socket object, rather than what the Shield's firmware might refer to.
My question is: Should the server socket quit listening for a new connection until the server closes the connection with client.stop()?
Pretty much yes.
There is more to it. You need to consider the relationship between a Socket and TCP. When we can talk about the SYN, SYN/ACK, SYN/RST and FIN packets, which are used to accept, reject, create and close sessions, I can tell you exactly what the Shield should do.
My tests have shown it never stops listening, and will accept another connection before the previous tcp connection on that socket is closed with client.stop().
It is actually worse than that but one thing at a time.
This is what the shield is doing;
+ Once the Socket is set to listen, the shield accepts up to 4 concurrent TCP session requests.
+ While the number of concurrent sessions is 4, further connection requests are ignored.
+ When the number of concurrent sessions falls below 4, the shield responds to any connection requests it has so far ignored. The client may have given up in the meantime.
+ The shield then accepts new connection requests.
There are up to 4 concurrent session. There is only one input buffer. Connections are accepted and data is placed into the buffer, independently of the sketch polling the SPI bus. Do you see the problem?
You can't really call the Server functionality a Socket, because it does not behave as a Socket must behave. The firmware does not separate the TCP endpoints. What we have is a session counter and a buffer which may contain data from different end points, interleaved within it.
Code to follow