From: ArdentlyGnarly <ard...@us...> - 2005-07-23 23:04:29
|
Update of /cvsroot/gaim/web/htdocs/summerofcode/jonathan/posts In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5121 Added Files: jonathan10.txt Log Message: There are 5 types of rendezvous proxy packets and things are going well. Exciting, huh? --- NEW FILE: jonathan10.txt --- Mysteries Revealed Today many mysteries of OSCAR's rendezvous proxy connection process became clear. I'll start with what I learned from reading over Keith Lea's code from the Joust project. There are still 5 blocks of information within the various packets of rendezvous proxies whose functionality is either unused or unknown; I have named them <code>unknownA, unknownB, unknownX, unknownY,</code> and <code>unknownZ</code>. The first 2 appear in the toward the beginning of a packet, the latter 3 appear side-by-side toward the end of packets. More on this later. Now, there are 5 types of packets that can crop up, each with its own "command type:"<br> 1) The Error Packet (<code>0x0001</code>) - Sent by the proxy server to let us know we've been naughty<br> 2) The "Init Send" Packet (<code>0x0002</code>) - This is sent by the first client that indicating that a proxy will be used<br> 3) The Ack Packet (<code>0x0003</code>) - This is sent by the proxy server in response to an "Init Send" packet<br> 4) The "Init Receive" Packet (<code>0x0004</code>) - This is the first message sent by the other client involved in the rendezvous connection<br> 5) The Ready Packet (<code>0x0005</code>) - This is sent by the proxy server in response to the "Init Receive" packet to indicate we're ready to proceed with our rendezvous connection as normal<p> On the coding front, things are going very well. Following Mark's advice, I am now happily sending packets using the <code>aim_bstream_send</code> function to send packets on their way. So far, I have successfully created a function to send an "Init Receive" packet and don't anticipate any trouble putting together one to send an "Init Send" packet. My first priority at the minute is tracking down the source of a few anomolous packets. The "Init Receive" packet must be the first one to reach the proxy server from our client or else the proxy server won't do business with us, but right now, Gaim is sending another packet before getting around to sending the "Init Receive" packet. With any luck, I'll be able to find the offending code and update it tomorrow. After that's done, I need to handle incoming rendezvous proxy packets (which speak neither FLAP or OFT). This means they will have to follow different code paths when they are received. In any case, I'm not too worried about things right now. Though I'm not as far along as I'd like to be, I should be able to finish things up before the deadline. |