-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XEP-0198 Stream Management #14
Comments
KeepalivesI've measured blackout (iptables -I OUTPUT -j DROP) scenario and after 17min of pinging into blackhole (whitespace or SM) the connection was finally terminated by the other side. This is unacceptable when we have 5-10 min of the SM resumption window. On the other hand if the ban is lifted (rule removed) within this 17min interval the TCP recovers and re-transmits the SM or WS pings (and receives responses) so that is faster that resumption. Therefore we do not impose any timeout on heartbeats - if the network changes the socket will receive RST and close the connection actively - which will be a case for resumption. Either way when SM is enabled we need to use SM ping instead whitespace (it is still smaller than iq) because we are doing selective acks hence need to catch-up the latest acks when idle. |
ResumptionThis is the most tricky part - not from technical implementation but from logical consistency. Ideally it should be managed from gabble - and most likely that's how it will be in the end, but so far trying to localize it in wocky, and maybe it will remain as an non-default option. Following challenges are identified so far:
The former could be solved by making WockyConnector reusable and passing it to the porter as part of SM context. The later may be achieved by making Porter reusable however that does not solve next tier problem - Gabble will also need to reset its state to reuse the porter and re-start initialisation (roster, etc.). Without interfering with Gabble (until it understands the SM) the only way is to make resumption failure fatal. |
Resumption TimeoutDuring my experiments with broken connection I came to know the timeout (specified by On the other hand there's UI problem - when connection is suspended and tries to resume - it does not expose this crippled state to the higher level. I.e. to gabble the connection is still connected, you can still send stanzas - but they (stanzas) will be queued and will eventiually timeout. Hence it must sooner or later give up resuming and go to disconnected state. And gabble should use its own stanza timeout value for that, rather than communicated To summarize - for client it does not make sense to honour SM timeout for resumption, it will continuously attempt to re-connect and resume connection when it runs in auto-resume (autonomous) mode. When the mode is managed (by gabble) it will timeout when upper layer thinks it's feasible. The idea behind leaving auto mode in place (currently it's only used for testing till gabble becomes sm-aware) is to be used in headless/non-interactive applications. |
The final draftBy final I mean that it looks complete enough to start building test units and gabble integration around it. Instead of explicit flow control I've decided to make assisted flow control via (interactive) signals. When porter detects connection failure, it prepares for resumption however right before calling connector's resume vector it fires The outcome of Since Finally if There are two more signals which are emitted when The signal The signal |
Couple of comments after completing gabble integration: First, gabble uses channel managers (which are wrappers to WockyTLSHandler and WockySaslAuth) and those are holding back-reference to GabbleConnection. That means that reusing original handlers from gabble is not viable - once gabble-connection is destroyed (due to reconnection) old handlers stop working. To circumvent this WockyConnector is modified to make handlers CONSTRUCT instead of CONSTRUCT_ONLY properties thus allowing their replacement from a new connection. Second - |
Some design ideas for SM based on review of early draft implementation (https://github.com/noonien-d/wocky/compare/0.18_XEP-0198_XEP-0352) and my own (unpublished) early attempt.
SM needs to live in the porter - as this is the place where stanzas are being queued/dequeued/sent and handled(!). Handled is a keyword for SM
h
attribute:Therefore neither XML Reader nor XMPP Connection do not fit this definition for received stanzas.
Connector initiates SM (enable) but then hands it over to porter which starts with zero counters. When porter receives
enabled
response it starts actively participating in the SM (requesting/answering). Porter needs to know though ifenable
has been sent so it starts fillingsent
queue.Porter will need to move sent stanzas(! not nonzas) from outgoing queue into (new)
sent
queue until it receives ack to head-drop the queue.Connector will also need to understand
resume
vector (perhaps viareg_op
). Resumption vector need to be handled by porter to avoid creating new one. In case of stream termination (not connection interruption) porter will just follow standard teardown vector, but for read/write errors it will discard connection and initiate resumption vector.The text was updated successfully, but these errors were encountered: