Hello,
we know for whatever reason time by time could happen that WIFI disconnects and reconnects. At that point, how to detect a UDP object that was in listening mode and get broken with the disc\recon? “parsepacket” and “available” unfortunately only continues to report zero bytes received. the workaround i’m thinking about is to open a dummy tcp socket and at any cycle check it. anything better that this ?
MT//Alex
by nature a UDP socket is not a reliable connection as it is a connectionless protocol. it just sends packets and doesnt care if they arrive or not.
yes sorry you are totally right. I thought that the message could be understood as you said but I was far from my pc. changed the title.
what I meant is that after a wifi disconnection a previously initialized UDP does not receive anymore. Only if you try to transmit you get an error and understand that a UDP stop\begin is needed.
What do udp.remoteIP and udp.remotePort say when you are in this state? That might help, I am not sure. UDP is “connectionless” i.e. stateless, but it is still point-to-point with a correct IP and MAC addresses required at both ends (unless you are using broadcast or multicast) So I am thinking the remote IP address will be all zeros in this case.
Ideally we should add a method to find out if the underlying socket is closed.
thanks for the hint, as soon as back at home I’ll give it a try.
yes exactly that at the moment the UDP library does not expose any method to check if and UDP object is still valid … or better the WiFi connect should re-validate the lost “sockets” but dunno if there is any underlying global that particle and user processes are sharing … or another is that WiFi can store the last connection time so with that user loop can trap a re-connection … or … or … 
Is this on a Photon or a Core?
hello,
it is about a Photon 0.4.5 … title updated
I think we can fix this in firmware. It should be possible to automatically reconnect all sockets after WiFi is disconnected, or if that isn’t possible we can at least add a status method on UDP to make it clear that a call to begin() is needed.
We’re experiencing the same issue and would also appreciate a way to detect this or have it be detected for us. It seems to happen when the router is reset.
the reason it breaks when the router is reset is simple, the router gets its IP address from a DHCP server at your ISP, when you reset it it gets a different IP address from the server, one way to stop this is to get a static IP address assigned.when the IP address changes, the “link” is broken as the address is no longer going to your router.best idea to stop this from occurring is to NOT reset your router.
Also when your router resets your devices connected to the router get new addresses assigned.
Hi,
if the router reset means WiFi off\on, is of course normal that you have to reconnect to a lost wifi. The IP change is not the reason and static IP does not solve.
For the sake of readers, issue reported by me is not about that. My disconnections happens every few minutes for no apparent reasons. and I’m talking of WiFi only, i.e.no cloud connection, which is known to cause a reset when not heartbeat is sent at last every 20 secs. … I suspect should be something about radio and too exigent stuff in the Particle firmware.
Anyway, whatever the reasons is we need a way to detect a lost UDP listener binding.
On the contrary, that is the EXACT reason a UDP link breaks, ALL packets have the IP address of the system it is being sent to in the packet, if that IP address no longer exists then the packet is NOT delivered.
UDP is a “connectionless” protocol, meaning that the sending system does NOT CARE if the packet arrives or NOT.! only in TCP protocol does the sending system REQUIRE an acknowledgement for each packet sent.
Whatever the cause of the disconnect/reconnect, the UDP socket seems to be invalidated. Even when the Photon is re-assigned the same local IP address, packets sent to it over the LAN are not received.