Search for
Login | Username Password Forgot? | Email: | Create Account
Non English | Popularity: 0 | Entries: 21 | Updated: 4h 8m ago | | Add to My Feeds
Mysteries Revealed
November 9th, 2006
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 unknownA, unknownB, unknownX, unknownY, and unknownZ. 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:"
1) The Error Packet (0x0001) - Sent by the proxy server to let us know we've been naughty
2) The "Init Send" Packet (0x0002) - This is sent by the first client that indicating that a proxy will be used
3) The Ack Packet (0x0003) - This is sent by the proxy server in response to an "Init Send" packet
4) The "Init Receive" Packet (0x0004) - This is the first message sent by the other client involved in the rendezvous connection
5) The Ready Packet (0x0005) - 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

On the coding front, things are going very well. Following Mark's advice, I am now happily sending packets using the aim_bstream_send 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.



More from Summer of Code

Status 06 Nov 9
Paydirt 06 Nov 9
Mysteries Revealed 06 Nov 9
Final Post 06 Nov 9
Documentation 06 Nov 9
Recent Progress 06 Nov 9
Testers Wanted 06 Nov 9
Breaking the Code 06 Nov 9
Squish 06 Nov 9

^ Back To Top