[zeromq-dev] zproto- terminated events

[Wes Young]

[for the search archives]

> On Feb 16, 2018, at 9:00 AM, Wes Young <wes at barely3am.com> wrote:
> 
> (looking at zgossip.c and zgossip_engine.inc, and using versions that are in-sync with current zproto master)
> 
> in zproto should a “termination” state trigger a socket disconnect (eg: a TCP FIN?) in the state machine? or is this something that needs to be handled in your server code? and it’s just assumed the TCP state stays ‘open’ unless you’ve implemented some lower level heart-beats or actually force a term of the tcp socket itself(?)
> 
> for instance- when zgossip triggers an expired/term event- the state goes to term and it appears to remove the client from it’s list(?), but it never seems to clean up the TCP connection unless there’s a hard disconnect. i can’t tell if this is on purpose and supposed to be done in the client, or if that’s just where folks left off last.. along with PING/PONG/TTL, zgossip.c:client_terminate is empty atm.

this is really more of a lower level zmq feature that i musta brain-farted on. the client is really responsible for the initiating a FIN, which is fine. the other issue seems to be, unlike other zproto protocols gossip *can* be really quiet at times. the zproto application server thinks the client is gone, but a FIN never went through (there was no lower level zmq disconnect). the other protocols seem to get around this issue by being more chatty, having longer timeouts and the correct implementation of PING/PONG which was started in gossip, but not quite finished (testing a PR for this).

also testing some TTL ideas that will influence the timeouts (eg: when things go quiet).

> i’m looking through the zproto docs and examples and think i’m just missing something dumb here.. might be mixing some terms too.

--
wes
wesyoung.me

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180224/fdedf294/attachment.sig>