I'm porting a project to the 1.0.1 IDE from 0022 and noticed something with the EthernetUDP library I wanted to verify...
My sketch has a lot of network communication, both with TCP and UDP services and I create sockets dynamically to avoid the 4 limit. However, with the new 1.0.1 UDP library if I create dynamic instances like this:
Udp udp;
udp.begin (port);
udp.beginPacket(serverIP, serverPort);
udp.write ...
udp.endPacket();
..then I will get a hang eventually which I traced to the UDP begin(). Looking at the Ethernet source I can see it was hitting the 4 socket limitation. So, I was not reaping my UDP instances correctly.
Now I know I can use (up to 4) static instances and it will be fine, but I really wanted to create dynamic instances to keep my memory low so I need to release the UDP instances properly.
The Ethernet library docs do not talk about using stop() for UDP (all the references are only to TCP and 'disconnecting from the server') but I do see a function in the UDP library source called stop() which appears to do the right thing; i.e. it will close the socket and make it available again.
/* Release any resources being used by this EthernetUDP instance */
void EthernetUDP::stop()
{
if (_sock == MAX_SOCK_NUM)
return;
close(_sock);
EthernetClass::_server_port[_sock] = 0;
_sock = MAX_SOCK_NUM;
}
The last line concerns me; why is it setting _sock to MAX_SOCK_NUM?
So.. is it correct to call UDP.stop() when I'm done sending my datagram and just a doc oversight?
Will calling stop() potentially interfere with a pending datagram from the endPacket()? (I do not like putting arbitrary delays in).
Chris