Timeout

[oiime]

Hey, I noticed the project is not being actively maintained recently so I'm not sure you're reading this, How would you go about adding a TTL feature to the protocol? I'm thinking of adding it myself and was wondering what would be the best way. The purpose is to trigger an error after emit if a given number of ms has passed. I can implement this by wrapping the response without a setTimeout but the message would still exist in the queue and pass on to the server

[alemures]

Hi oiime! This proyect is active and i'll be glad to help you, in this case, it will be quick!

The library already has the functionality you are looking for, check out the method called Sock#setTimeout(timeout) in http://alemures.github.io/fast-tcp/Sock.html

Sock is the super class of client and server sockets so, it will be available for you to use in either side.

[oiime]

Hey, thanks for the prompt response. that setTimeout as far as I understood is to add a timeout to the socket itself. my intention is adding a TTL to a call to allow releasing of hanging callbacks, ideally it'll be passed as an argument to the cb.

eg:
When emitting:

socket.emit(eventName, data, { ttl: 5000 }, cb)

then if a ttl option is given internally set something like:

this._ttl[messageId] = setTimeout(function (sock, messageId) {
    sock._acks[messageId](null, new TimeoutError('time out')); // cb (err, payload) switched for compat
    delete sock._acks[messageId]
}, this, messageId)
// _onMessage (and _flushQueue?) would release the setTimeout according to the messageId

this is however problematic as the message would still be sent as it is already in the queue (either in the socket level or in the library queue). I guess that could be somewhat worked around if using ttl requires using the library's queue and the queue checks and releases this._ttl prior to sending over to the server. but that would not be ideal as using a queue is somewhat antithetical to predictable ttl

[alemures]

Hi @oiime , after a while since our last conversation, i think i have a good solution for your suggestion.

socket.emit('theevent', 'thedata', { timeout: 50 }, (result) => {
  console.log(result);
});

Few things to add about my actual solution:

• timeout will only work for messages with a callback.
• result in the callback will be an Error instance if a response from server isn't received within 50ms (don't know yet if two params will be better, first one with Error or undefined and second one with the received data).
• When the timeout Error is thrown to the callback, there are two possible situations:
  • The message is still in library queue so, it will be removed and will never be sent.
  • The message was already sent and a response would be received, in this case, it will be rejected as soon as it arrives.

Any feedback is welcome =)

[alemures]

About the second point, i just decided to go for the two parameters option, the ack callback will always be called with (err, data).

[jjp91]

Hello,
This request is important to me too, if I can ask for a modification on timeout.

I can wrap what i am asking, so feel free to decline if bothering.

I tested callback on emit on rooms, (if my tests are correct, may be i am wrong, sorry if it is the case) it seems not to work, and it is normal, because there might be multiple members.

This is the point, callbacks could work on rooms, if the caller accept all answers within the timeout, and when the timeout is reached, a last callback is launch with error = 'close' or something like that.
And if a timeout is not set, the answer is closed on the first answer.

It could be usefull, to synchronise things between members. elect master for clustering processes/servers when a process/server is down ...

PS: Your module is really great, sincerely, thank you. I will do benchmarks, but i am sure it is a good challenger to NATS.

[oiime]

Hey, sorry for the late response, I definitely agree that (err, result) is the correct format, it's an almost universal standard at this point. I think that the nature of the error should denote what state it "timeouted" in, there could be a big difference in application behavior to a timeout in queue and a timeout waiting for server response, they are inheritly different errors.

Thanks