Tested. Keeps code from initializing too many sockets, even when the sockets aren't used initially.

I'm not clear why only socket #0 can be used for DNS. There's a use case where sockets use IP address rather than host names, and this reduces the available sockets. I don't know whether it's better to reserve a DNS socket, or raise an exception if the application uses too many sockets (like other uses of sockets).

edit: I don't see the linkage that enforces DNS to use socket #0. In a test, it seems to be fine with other sockets:

*** Opening socket 3
* Opening W5k Socket, protocol=2
* DNS: Sending request packet...
* socket_available called on socket 3, protocol 2

If that's the case, then I lean toward allowing the user code to use all available sockets, and raise an exception if it uses too many (for whatever purpose).

P.S. raw socket I think is needed for ping, but I don't see that ping is implemented in this library

Good question.

My thought process was:

1. If all the hardware sockets are assigned to socket.socket objects, then calls to maintain the DHCP lease and to socket.gethostbyname() will always fail.
2. It is reasonable for the user to assume that calls to maintain a DHCP lease and to socket.gethostbyname() should succeed, therefore keep one hardware socket free for these calls.
3. If one hardware socket is to be reserved, let it be socket 0, because it has some unique features that might be useful in the future.

So, by leaving one socket free, these other calls will succeed.

edit: I don't see the linkage that enforces DNS to use socket #0. In a test, it seems to be fine with other sockets:

Currently DHCP and DNS modules both import socket and use that. There's PR for DHCP module to use direct calls to the Wiznet chip instead of the socket module. I'm working on doing the same for the DNS module at the moment.

If a call is from anything other than a socket.socket() it tries for hardware socket 0 first. If that is busy it will try the remaining sockets. DNS calls will not be restricted only to hardware socket 0.

This PR works with the current version of the Wiznet5k library, but is written with a future versioning mind, where DHCP and DNS make direct calls to the Wiznet hardware instead of instantiating a socket.socket().

I'm fully open to just allowing all the hardware sockets to instances of socket.socket if that is the preferred option.

Also, this PR might be shelved as a draft until the updates to DHCP and DNS have been merged.

I forgot about DHCP, which I think is also UDP, though I never understood why it's needed at the user level when all of the other CircuitPython networking environments don't. Somehow, DHCP doesn't seem to cut into the socket count in other environments either, but I don't know how that could be?

You have a lot planned, you may want to involve @brentru, or someone else with more knowledge of this library than me. I'm always happy to test, but not the best one for code reviews

I forgot about DHCP, which I think is also UDP, though I never understood why it's needed at the user level when all of the other CircuitPython networking environments don't. Somehow, DHCP doesn't seem to cut into the socket count in other environments either, but I don't know how that could be?

You have a lot planned, you may want to involve @brentru, or someone else with more knowledge of this library than me. I'm always happy to test, but not the best one for code reviews

If the WIZNET5K instance has is_dhcp=True then an instance of the DHCP class is created by WIZNET5K. Periodically the T1 and T2 timers have to be checked to see whether the DHCP lease needs to be renewed. It is strange that the user is expected to make these checks. They could be incorporated into one of the WIZNET5K methods to automate it.

The DHCP protocol doesn't take any action until the T1 timer (50% of the lease time) expires. Then it periodically attempts to renew the lease. This renewal attempt will definitely require a hardware socket, however if the lease is e.g. 24 hours, then you would have to wait for 12 hours with all the hardware sockets assigned for the problem to manifest itself. This may not show up in testing.

@brentru does pop in every now and then.

I greatly appreciate your comments and testing. Thank you 😃

BTW, I do think that the assumption that there will be a close or with exiting to free up the socket is reasonable. Anything else risks stealing away the socket from some further use.