TCP socket.receive({timeout: -1})

[nodakguy]

Does a receive timeout = -1 mean the thread doesn’t block at all? As opposed to timeout = 0, where (I believe I read in a prior post) the thread blocks indefinitely? Thanks!

[bill (Bill Venhaus)]

I don’t think the TCPClient honors the timeout option. It will always wait for data. Use the available property to see if it has any data ready. If it’s empty (0 bytes) & you call receive, it will block/wait for data to arrive.

TCP client receive() call not honoring timeout

The receive timeouts aren’t working for me either. I only tested the simulator. Didn’t try in the actual apps. There isn’t going to be much I can do to fix this because those are set on the system class. The only other way I can abort the receive call is by doing a close which I do not want to do in this case. The next release is going to include a new available property on the TCPClient. This will return the number of bytes that are currently in the receive buffer. So instead of using a timeou…

[nodakguy]

Thanks Bill, I fully accept your response, but I think I didn’t frame my question in the proper context. Within the framework of a TCP plugin (eg TiVo or DenonAVR) I’ve seen the onPoll function implement “socket.receive(options)”, where in some cases options = {timeout:-1} Starting from basics, my question(s) are:

1. Could socket.receive() still be considered a legitimate function call within onPoll? I’m not TCP-fluent, but I’m not sure how else to receive a TCP payload.
2. If so, could options = {timeout:-1 } still be a valid parameter to pass into socket.receive(options).
3. If so, what does options = {timeout:-1}, vs {timeout: 0} or {timeout: 250} accomplish?

Thanks again.
Regards, Terry

[bill (Bill Venhaus)]

@nodakguy

Could socket.receive() still be considered a legitimate function call within onPoll? I’m not TCP-fluent, but I’m not sure how else to receive a TCP payload.

Sure, why not? That’s where it should be 99% of the time. Don’t bother setting the timeout option because it doesn’t work. It will behave the same no matter which value you supply.

People sometimes get confused about how polling works. Read what I wrote here & should clear things up:

Polling and keeping devices in sync

The PollingInterval is not the rate at which onPoll is called. It is a delay between consecutive calls. This probably should have been named PollingDelay to avoid the confusion. The TCP receive function is a blocking call. On initial connect there are probably quite a few messages coming in which will explain why it is called 4 times. Then after that it’ll likely reach a sit & wait situation which is expected. There’s nothing wrong with that. I myself actually wrote that Plugin for the Monopric…

[nodakguy]

Works for me - thanks!