Sorry for the really really late response. We had solved this by making the connection manager slightly more intelligent and introducing inter CM routing for such packets.
Note that since for security reasons we would not prefer CM to be in http - cookie's are not going to be of much use anyway. Ignoring that temporarily, most CM containers (tomcat, appserver,etc - not the CM itself) already set some cookie or other. Additionally, most LB's loadbalance dont simply do loadbalancing based on round robin but can be configured based on other criterion (cookie would be one - if http, else IP, subnet, others etc). So probably requiring or worse mandating this for CM would not be a nice idea. Regards, Mridul ----- Original Message ---- From: Peter Saint-Andre <[email protected]> To: Bidirectional Streams Over Synchronous HTTP <[email protected]> Sent: Thu, 1 October, 2009 12:09:22 AM Subject: [BOSH] HTTP session IDs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Because of how HTTP is deployed, there might be intermediaries between a BOSH client and a BOSH connection manager (CM). Such intermediaries might include proxies, caching servers, and load balancers. Some of these entities, especially load balancers, might redirect an HTTP request from the client to a different CM. Here is some pretty ASCII art that shows one possible deployment: +----+ -------> CM1 Client -----> | LB | -------> CM2 +----+ -------> CM3 Let's say that the Client sends an initial request that the Load Balancer direct to CM1. Unless CM1 can tell the Client to send future requests to CM1 (e.g., via an HTTP header or a cookie) in a way that the Load Balancer will pass through, future requests from the Client might be directed to CM2 or CM3, but those CMs know nothing about the Client's BOSH session because only CM1 knows about the session. Discussions with implementers have led me to conclude that the best way to do this is for the CM to set a temporary cookie on the client (containing a session ID) in its response to the first BOSH request, and for the client to return that cookie value to the CM when it sends future requests during the life of the BOSH session. Many application servers (e.g., Tomcat) use such session IDs and some BOSH CMs are probably written on top of such app servers, so they already have support for session IDs out of the box. In the absence of such an app-server-specific session ID, deployment experience has shown that it would be useful to define a BOSH session ID. Basically the value is just an opaque identifier as far as the client is concerned, although it might have meaning to the BOSH CM (in fact, it might simply be the BOSH sid from XEP-0124). Although we don't necessarily need to standardize this in XEP-0124, I think it would be good to define a conventional name for the session ID so that we have improved interoperability across different connection managers. I propose BOSHSESSIONID as the name for this session ID. If people would find it helpful, I could add a short informational note about this to XEP-0124. 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/ iEYEARECAAYFAkrDpdoACgkQNL8k5A2w/vwkCACffbl8zBmSlRYWzGGW7rWBpeLi 758Ani8LAa7x/14MwnMOxs4ShkEFoqoH =R9bz -----END PGP SIGNATURE----- The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
