-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/5/09 12:38 AM, Philipp Hancke wrote: > 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.
Correct. Isn't that up to the implementation or deployment? >>>>>> * 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. What are the race conditions? I can add sending domains for my side and you can add sending domains for your side. Now I suppose that if you try to add foo.com as a sending domain for you, and I try to add foo.com as a sending domain for me, we have a problem. But presumably only one of us will have appropriate credentials to send for foo.com, at least in the typical s2s scenario (things might be different inside a cloud). >>>>>> * 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! OK. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoAUIsACgkQNL8k5A2w/vymgwCeL+xIEpbXBFlxOPXrJI5YJovs Yk4AoLiDLMueJi0bSzlHx5EG74Uu200e =HuiY -----END PGP SIGNATURE-----
