<div>I've paused working on the Instant message system to investigate in greater detail what would be entailed in using XMPP to transmit online presence data, one to one instant messages, and one to many instant messages and I've essentially gotten that none of the specs or drafts really take advantage of the inherent scalability of grid computing.</div>
<div> </div>
<div>Lets start with the pitfalls of the approved XMPP Spec</div>
<div>*Requires constant TCP streams</div>
<div>*Requires a central server.</div>
<div>*To add more load capability, you add another central server. Each central server is allocated by domain in DNS.</div>
<div> </div>
<div>In large scale applications, I think it's clear that constant TCP streams are not the way to go. And IMHO polling isn't either.</div>
<div>So that leads us to one of the Drafts of the XMPP spec</div>
<div> </div>
<div>XMPP over BOSH(Bidirectional-streams over synchronous HTTP)</div>
<div> </div>
<div>However, this spec only defines the possibility of having a HTTP Gateway, which translates to open TCP streams. So, once again, we end up with open TCP streams. Essentially the Region Host would have the open TCP stream to the XMPP server. Once again, this is limiting to growth. Given that low use TCP servers struggle to handle >=5,000 connections. That essentially limits your XMPP server to 5,000 regions or less. Probably less given that there could be up to N users in a region.. which would turn it from a low use connection, to a high use connection.</div>
<div> </div>
<div>Therefore, at least in my opinion, none of the barrage of XMPP specs are not suitable for this application in general use. </div>
<div> </div>
<div>However. I'd like to note that if each Instant Message has a region domain associated with it and the regions are responsible for connecting to other regions to deliver instant messages then we get massive scalability automatically. In addition, to provide outside interoperability with XMPP servers, a XMPP module could be built to communicate with the outside world using XMPP. The 'region domain' on the Instant message could lead to the XMPP over BOSH gateway for people who have chosen to connect to IM only applications. The user would have the XMPP Gateway as the 'region that the Instant Message Module' thinks they are at. </div>
<div> </div>
<div>In this example, substitute User Server with whatever server you've got set up to handle it. Such as the Message Server.. Grid Server.. etc.</div>
<div> </div>
<div>To put the Presence/IM flow into perspective:</div>
<div>1. User A - logged into a region</div>
<div>User B - logged into a region</div>
<div>User C - logged into a region</div>
<div>User D - logged into a connected Jabber server</div>
<div> </div>
<div>2. User A is friends with User B</div>
<div>User C is Friends with User A</div>
<div>User A is friends with User D</div>
<div>Therefore by the transitive</div>
<div>User B is friends with User A and User A is friends with User C by the transitive.</div>
<div>However, User B and User C are not friends with each other</div>
<div> </div>
<div>3. User A, B, C, and D are part of a Group</div>
<div> </div>
<div> (for our purposes lets say the friend list is a representation of a presence subscription list that automatically gets subscribed to on both sides, presuming that the friendship rules say that User X has given User Y permission to see them online and User Y has given User X permission to see them online)</div>
<ol>
<li>User A signs on.</li>
<ol>
<li>The User server determines that nobody is online in User A's friendlist to notify</li>
<li>end.</li></ol>
<li>User B signs on.</li>
<ol>
<li>The User server determines that User A is connected and that User B is in a region/simulator</li>
<li>User Server sends a notice through the simulator that they are in that A is online to User B</li>
<li>User Server sends a notice through the simulator that they are in that B is online to User A</li>
<li>end</li></ol>
<li>User C signs on.</li>
<ol>
<li>The User server determines that User A is connected and that User C is in a region/simulator</li>
<li>User server sends a notice through the simulator that they are in that A is online to User C</li>
<li>Users Server sends a notice through the simulator that they are in that C is online to A</li>
<li>end</li></ol>
<li>User D signs on the jabber server.</li>
<ol>
<li>The jabber server notifies the user server through XMPP over BOSH, or parhaps straight XMPP</li>
<li>The user server translates the friend list to <iq> stanzas</li>
<li>The jabber server sends the subscription requests, which get translated into presence requests on the User Server</li>
<li>The user server notes that User A is online and in a region</li>
<li>User Server sends a notice to User A that User D is online.</li>
<li>User Server sends a Presence stanza to the XMPP server regarding User A's Online status</li>
<li>User Server sends a notice to the region that User A is in about User D's status</li>
<li>Region Server notifies User A</li>
<li>end</li></ol>
<li>At this point we have A, B, C and D Online, and all users have properly updated presence.</li>
<li>User A signs off.</li>
<ol>
<li>User server determines that User B, C, and D are on User A's friend list</li>
<li>User Server sends the simulator that has the open connection with User B the notice that User A logged off</li>
<ol>
<li>Region server informs User B</li></ol>
<li>User Server sends the simulator that has the open connection with User C the notice that User A logged off</li>
<ol>
<li>Region server informs User C</li></ol>
<li>User server sends a presence stanza to the XMPP server/Gateway to notify User D</li>
<li>end</li></ol>
<li>A this point we have User B, C and D online all with properly updated presence</li>
<li>User A signs on again</li>
<ol>
<li>User server sends a notice to the simulator B, and C are in with presence notifications</li>
<li>User server sends a presence stanza to the XMPP server/Gatway with the proper session ID</li>
<li>end</li></ol>
<li>User A sends a message to User B.</li>
<ol>
<li>User A's Region either knows where User B is or looks up the information from the User Server</li>
<li>User A's Region connects directly with User B's Region and delivers the message to User B's region. </li>
<li>User B's Region delivers the message to User B and caches the location and information of User A's Region</li>
<li>end - Message Delivered</li></ol>
<li>User A sends a message to User D.</li>
<ol>
<li>User A's region knows where User D is (the Jabber server/XMPP Gateway).</li>
<li>User A's region connects directly with the JabberServer/XMPP Gateway and delivers the message stanza caches the user's location.</li>
<li>end - Message Delivered</li></ol>
<li>User D sends a message to User A</li>
<ol>
<li>The Jabber Server/XMPP Gateway over BOSH sends a HTTP Request to the region the user is in and sends a message stanza.</li>
<li>User A's Region notifies User A.</li>
<li>end - Message Delivered</li></ol>
<li>User B opens up a Group session with User A, C and D</li>
<ol>
<li>The User Server establishes a forwarding session with three regions and the XMPP Server</li>
<li>The User Server establishes a group session with the XMPP Server.</li>
<li>The XMPP Server informs the XMPP Client (User D) that there's a group session starting.</li>
<li>Message from User B gets delivered to User A's Region and User C's Region. </li>
<li>A Message Stanza gets sent to the XMPP Server with the group session ID from the User Server.</li></ol>
<li>User D sends a message in the group session</li>
<ol>
<li>The Message gets sent to the appropriate users on the XMPP Server and gets sent to the User Server.</li>
<li>The User Server sends the message to User A, B and C's Regions.</li>
<li>The Regions delivers the message to the users.</li>
<li>end</li></ol></ol>
<div> </div>
<div>Assumptions: </div>
<ol>
<li>Regions can contact each other's HTTP port and Regions can contact the Jabber Server/XMPP Gateway over BOSH.</li>
<li>Card based group sessions are just dynamic group sessions. Other then their dynamic nature, they function exactly the same as a session established by a pre-existing group.</li>
<li>Eventually Group sessions will time out if there's no activity.</li>
<li>The user server either periodially notifies subscribed user A's regions about which region User B is in. Presumably in border crossings, etc, or this is looked up per instant message</li></ol>
<div> </div>
<div>:D A little more complicated then it looks at first hmm?</div>
<div> </div>
<div> </div>