This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
oeed's profile picture

Suitable Modem Timeout

Started by oeed, 16 December 2014 - 10:38 PM
oeed #1
Posted 16 December 2014 - 11:38 PM
I'm making a fairly simple modem API. One of the things is uses is callback functions for replies, like so:


-- computer 1
communicate:SendMessage('ping', 'Ping!', function(message)
	print(message.content) -- Pong!
end)

-- computer 2
communicate:RegisterMessageType('ping', function(message)
	return 'Pong!'
end)

Everything works fine, but I'm sure about what the lowest reasonable timeout is. The shorter the better really, although I don't want to miss messages. The reply is sent immediately (based on the return value), so it's not like there's a massive delay involved.

So yea, simply put how low can I reasonably set this timeout?

From experiments with os.time and os.clock I get a response virtually instantly, the time/clock value doesn't change. Although that's on SP.
Edited on 16 December 2014 - 10:59 PM
theoriginalbit #2
Posted 17 December 2014 - 12:23 AM
it really depends on the context and importance of the message. Some messages a timeout of 4 seconds might be appropriate, but other times a timeout of 0.5 could be too much. I think it could just be beneficial to be specified at some point to the api as to what the default is, otherwise making to small.
Bomb Bloke #3
Posted 17 December 2014 - 07:02 AM
The main factor in how long a given message will take is how many other computers are running and how long they spend running code in between yields. Figure out the maximum amount of time a given system can block for, add a couple of seconds to that, and you've got the minimum value you're likely to get away with.

I'm not really sure it matters much. So long as you're not flushing the event queue out on a regular basis (by using eg sleep), you should be getting all messages anyway. I mean, sure, modems have a habit of failing to deliver one message every thousand or so, but if users need to ensure reliability then they can code in a resend mechanism themselves.