I have a question regarding the W5100’s receive and transmit memory size registers when I initialize the IC. The IC’s datasheet provides an example where I would initialize them with the value 0xAA. Sockets 2 and 3 become unusable. However, that example does not answer my question.

Suppose I initialize them with the value 0x2E, i.e.,
Socket 0 is allocated 4 KB of space,
Socket 1 is allocated 8 KB of space,
Socket 2 is allocated 4 KB of space,
Socket 3 is allocated 1 KB of space.

Socket 0 works. Socket 1 is obviously garbage because it is asking for resources that don’t exist. Does Socket 2 work? There is adequate space for it. Or is it that because Socket 1 is trash, all further sockets won’t work? Socket 3 will obviously not work either, whether or not Socket 2 does.

In my code, I can easily manage which sockets are usable/unusable given allocation requests.

Calculations are made that go with usage of application memory.
Usually the problems are only in reception and in server mode where most applicants must be able to connect.
If you have to use it as a server in response to HTTP connections as buffer just have 1 or 2K, and you can open 4 socket for receiving.
If the answer is SOAP / HTTP you need at least definitely 2K and act accordingly on the buffer.
The two examples above are resolved in the request / response with disconnection of the socket and make it accessible to other incoming requests in pseudo concurrent mode.
In persistent connections where it provides a communication without interrupting of the socket (type transmission / receiving files) then it all depends on how much time available you have in the main process before to pack a response.
I have been clear enough?
In short, if you have to communicate continuously with a single user at a time, I recommend using the entire buffer to a single socket connections while in one shot comunications you can ride in the division of the buffer based on how many concurrent connections you want to have.

Thank you for your response. You have been clear enough, but it does not answer my question. Your post will aid me in the future about recommended receive/transmit memory allocation. Maybe the following will help.

I am not writing an application. I am writing an interface library for the W5100. This library contains a class. When an object of this class is instantiated, some of the object’s data is initialized with reasonable defaults, defaults we are familiar with, such as receive and transmit memory sizes of 2KB for all 4 sockets (0x55). During this object instantiation, the W5100 is not initialized, and the W5100’s RMSR and TMSR registers are not written to. That happens later. After object instantiation, a user has the option of changing some of the object’s public data, customizing the object, tailoring it to his/her needs. Then he/she initializes the W5100 through this object (via some function).

I’m giving this user the ability to determine how to size the sockets that suits their needs. This means they are allowed to give me bad values for RMSR/TMSR, such as 0x2E or 0xFF, and it is my job to recover from this. By “recover,” I mean the object will know which sockets are usable and which are not usable, and the object will not allow a user to interact with a bad socket.

Suppose the object receives 0x10 for RMSR and 0x2E for TMSR, i.e., a user requests
1 KB of receive buffer space and 4KB of transmit buffer space for Socket 0,
1 KB of receive buffer space and 8KB of transmit buffer space for Socket 1,
2 KB of receive buffer space and 4KB of transmit buffer space for Socket 2,
1 KB of receive buffer space and 1KB of transmit buffer space for Socket 3.

Which sockets will work? Socket 0 only? Sockets 0 and 2? None of them? All of them with undefined behaviours?

I hope this is clearer.

OK, from DHCP WIZNET source,
the easiest way is to assign on climb the available buffer and when if is over then declare ramining socket unusable and flag it.
Keep in mind that the socket 0 has also any particularities compared to others, that I not remember now but that you find on the datasheet, then say remains the master socket.

OK, that helps a lot. I should have fun coding the library then. And yes, I do remember reading something in the datasheet that Socket 0 has some particularities. I don’t know what they are, but I do remember seeing something.

Thanks tons.