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 naughty2) The "Init Send" Packet (
0x0002) - This is sent by the first client that indicating that a proxy will be used3) The Ack Packet (
0x0003) - This is sent by the proxy server in response to an "Init Send" packet4) The "Init Receive" Packet (
0x0004) - This is the first message sent by the other client involved in the rendezvous connection5) 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.
