Peter Saint-Andre wrote:
Do you mean: when does an application decide that it would like to
request multiplexing for a given domain (rather than opening a new XML
stream)?
yes. Rather than opening a new TCP connection actually.
* The multiplexing method must be backwards-compatible with
existing
server-to-server connection methods.
* Each party to a server-to-server communication must be able to
determine if the other party supports multiplexing.
unidirectional or bidirectional s2s for this? For bidi we need a
reverse-stream:features feature anyway.
I think this should make the stream bidirectional.
If it is bidirectional, who can add new domains? But that is probably
digging too deep already :-)
I would think that either side can add domains (if adding domains has
been negotiated).
Might result in race conditions. One way to avoid that is a protocol
where one side asks the other side to add the domain. Not that
difficult to solve.
* If the addition of a new domain to an existing domain-to-domain
stream fails, the existing stream must not be terminated.
if the addition of a new domain to an existing stream fails, is it
allowed to retry after x minutes?
Sure, why not.
An alternative would be that a failure is considered permanent -
blocking communication with that domain - and the remote end notifies
the initiator if this situation changes.
That puts the burden on the receiver, which seems wrong.
push vs poll... but that approach is flawed anyway. Retry!
philipp
