[ch1668] UDP socket validity check

[aledand]

sockets become invalid after a WiFi reconnect. this should let user code to check it.

[m-mcgowan]

This is great. Would you mind adding docs and tests to support this change? Details are in our contributions doc - https://github.com/spark/firmware/blob/develop/CONTRIBUTING.md. Thanks!

[aledand]

So far not so much time for the full chain, I'll do my best.

[m-mcgowan]

Any objections to merging this?

In our discussions on logging today, calling read/write and other operations on TCP/UDP objects that are not valid is a good example of where we'd emit a WARN or ERROR log.

[aledand]

no of course no objections

[m-mcgowan]

@aledand - would you please sign our CLA - https://docs.google.com/a/particle.io/forms/d/1_2P-vRKGUFg5bmpcKLHO_qNZWGi5HKYnfrrkd-sbZoA/viewform.

For consistency, we should add an isValid() also to the TCPClient object (and TCPServer). I can add that if you don't have time for it.

[aledand]

done

Il giorno mer 27 apr 2016 alle ore 23:21 Matthew [email protected]
ha scritto:

@aledand https://github.com/aledand - would you please sign our CLA -
https://docs.google.com/a/particle.io/forms/d/1_2P-vRKGUFg5bmpcKLHO_qNZWGi5HKYnfrrkd-sbZoA/viewform
.

For consistency, we need to add an isValid() also to the TCPClient object
(and TCPServer) and provide a simple API that tries to automatically
reconnect disconnected networking instances (as described in #982
https://github.com/spark/firmware/issues/982) plus a system event when
network interfaces come and go so more advanced applications can interact
with that and introduce their own handling.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#766 (comment)

[technobly]

Closing until tests can be added for this. Added to Clubhouse 1667.

[technobly]

We currently have TCPClient::status() that acts this way, validating the TCP socket, although it needs to be documented (particle-iot/docs#569). Perhaps this PR should rename the API to UDP::status() and && it with .ready() like TCP does and use the isOpen(_sock) function instead of duplicating that code.

For reference, TCPClient::status() is

uint8_t TCPClient::status()
{
  return (isOpen(_sock) && Network.from(nif).ready() && (SOCKET_STATUS_ACTIVE == socket_active_status(_sock)));
}

So proposed UDP::status() would be

uint8_t UDP::status()
{
  return ( isOpen(_sock) && Network.from(nif).ready() );
}

Unclear if socket_active_status(_sock) can be used with UDP... need to research.

---

This would address issue #1243

[Pixinger]

Hi, sorry for posting in a closed topic.
But as this topic is closed and me having the same issue with UDP validation, I just wantet to ask what the current state of this problem is. Does CLOSE mean "it will not be done", "already done" or "out of men power"?
I help myself with regularly checking WiFi.ready(), but as Barakwei in this issue #1243 pointed out, this is not a good solution.
Please don't feel offended, I just did not know a better palce to ask.
Best regards, Pix

[stewartadam]

What's the current status of this? This is closed, but the PR for documenting these calls is open and it seems neither Udp.status() nor Udp.isValid() are present in the 0.7.0 release despite these PRs dating years ago.

[bkobkobko]

Hi @stewartadam

I am not sure what is up with this pull req, but I did want to make two points:

1. This pull as written would not appear to me to work correctly--it does not do the test properly.
2. As a work-around, you can figure the status by calling retVal = udp.receivePacket(...); since it returns -1 for socket problems, 0 for nothing to get and positive values for actual bytes received.