I’m using an Arduino Wiznet Ethernet W5100 shield with an UNO.
It’s set up and running and configured to receive data from a web browser via the POST method and dump it 1 character at a time to the serial monitor.
It works but I’ve run into a ~2KB receive limit. Posting a data string larger than 2KB results in data just being lost.
Looking to send about 250KB (quarter of a MB) back from the browser to the UNO via the W5100.
I’m using the client.available() and client.read() methods to test if there is data to read, and then read it. I works for data streams less than 2KB.
There are other posts on this but no resolution:
I understand that there is only an 16KB buffer on the 5100 (source:datasheet), and that this is shared across 4 sockets (4KB per socket), but cannot see why this would limit received data on a TCP\IP connection.
TCP\IP is a stateful protocol, meaning there is a handshake between nodes (unlike UDP\IP which is just broacast). It allows for traffic negotiation (flow control), so the receive buffer size shouldn’t be an absolute problem (not dropped packes when the buffer is full anyway). The data sheet for the 5100 states:
The W5100 includes fully hardwired, market-proven TCP/IP stack and integrated Ethernet
MAC & PHY. Hardwired TCP/IP stack supports TCP, UDP, IPv4, ICMP, ARP, IGMP and PPPoE
So the TCP\IP stack is implemented in hardware, and the designers must have known about the receive buffer limit when the stack was implemented, so why are packets just dropped when the buffer is full? As ‘westfw’ states in the first post, ’ a TCP window smaller than the available buffer memory (should be set), which should prevent the remote host from ever sending a packet that won’t fit’.
TCP windows are set at the stack level right? Is there any way to set it?
If this really is a stack implemention ‘feature’ on this chip, are there any ways round it?
I tried playing with the memory allocation for sockets (the datasheet does elaborate on this a bit). Modified .cpp code and you do get a bit more recieve buffer, but not much and that’s still at the expense of available sockets if allocation is high.
Another option would be to open and close multiple connections in series, posting <2KB each time. Not standard browser behaviour though.
Any suggestions appreciated.