ICQ TCP Protocol as used by STRICQ Written By: Douglas F. McLaughlin $VER: STRICQ TCP Protocol 0.99a 11.30.99 Table of Contents 1. Introduction 2. Starting with UDP 3. Switch to TCP 4. The TCP Init Packet 5. The TCP Message Packet 6. The Message ACK Packet 7. TCP Message Related #define's 8. Other Forms of the TCP Message Packet 9. Reverse TCP Connections 10. File Direct Protocol 11. Chat Mode Protocol 1. Introduction This text will hopefully help explain a lot of the details of ICQ's TCP protocol version 2 (v2). Not all available codes and packets have been completely deciphered, however, these packets are VERY rare and therefore hard to intuit a specific meaning. First of all, this text would not be possible were it not for the help and hard work of a few other people. A small portion of the DEFINEs are based upon work done by Matt Smith author of micq. Most of the basic format of the TCP Message and Chat packets were worked out by the author of Licq (whose name I can't remember right now.) The basis for the TCP File Direct packets comes from the source code icqfile.cpp. This document and the final meshing of all this information into one protocol was done by Douglas F. McLaughlin author of STRICQ for the Amiga computer. (And Mirabilis said it couldn't be done!) Please do not spread this text without applying full credit to its author and the author's sources as mentioned in the paragraph. Finally, this document assumes a good working knowledge of opening and using TCP sockets and how to manage multiple open sockets at once. This includes how to use listen() sockets. 2. Starting with UDP To begin working with TCP, you must start before your client ever logs into the ICQ server. At the same time as the UDP socket is created, you need to also create a listen()ing TCP socket and obtain its IP and port for sending with the initial login packet sent via UDP. Your initial IP can be obtained by using gethostname() and then gethostbyname(). The PC ICQ clients always provide the client's LAN IP in favor of any ISP provided IP. Also be sure to set the client to client flag to 0x04 in the login packet so that other clients will know that your client is TCP capable. ULONG TCP_MsgPort; /* Port your client will accept TCP connections on. */ UWORD PassLength; /* Length of password text. */ char Password[]; /* Password, max 8 characters, case sensitive. */ ULONG X1; /* Unknown. Use 0x00000000 for v2. */ ULONG TCP_MsgIP; /* IP Address your client will accept TCP connections on. */ UBYTE TCP_Flag; /* Is your client TCP capable? 0x04 = Yes, 0x06 = No. */ ULONG Status; /* Your client's status at login. See defines. */ ULONG TCP_Ver; /* The version of the TCP protocol used by the client. */ UWORD Seq_Login; /* One up for each login packet sent. */ ULONG X4; /* Unknown. Use 0x00000000 for v2. */ ULONG X5; /* Unknown. For best results use 0x007300D9 with v2. */ Before moving too far along, it must be noted that each type of connection creates its own listen()ing socket. i.e. Message, Chat, and File connections will each have their own dedicated listener. STRICQ follows the same convention as the PC client in that the Message socket is created at 'go online' time and the other two types are only created when that event occurs. A chat listen socket is created only when someone requests a chat, the same for a file send/receive. Next we move to the S_USER_ONLINE (0x006E) packet. The important information contained in this packet are the IP, Port, and TCP flag fields. The IP and Port are obviously necessary for making a direct TCP connection. The IP address is the IP that the ICQ server has extracted from the initial login UDP packet header NOT the IP in the login packet itself. The Real IP is the IP provided by the client in the login packet, most often this is just a copy of the first IP, however, if the client found a LAN address, this will be the client's LAN IP. Use the one byte TCP flag to determine whether a message packet should be sent via TCP or UDP. If the flag is 0x04, attempt a TCP connect, otherwise send the message via UDP to the server for final delivery as an online message. Usually, if the client is not TCP capable, then some kind of firewall/proxy is involved that blocks TCP connections. ULONG UIN; /* The UIN of the user that is online. */ ULONG IP; /* The IP address of the client (LAN External.) */ ULONG Port; /* The Port to connect() with for sending messages. */ ULONG RealIP; /* The actual IP of the client machine (LAN Internal.) */ UBYTE TCP_Flag; /* TCP Flag, 0x04 = TCP Capable, 0x06 = Do not use TCP. */ ULONG Status; /* The status of the user at login. */ ULONG TCP_Ver; /* The version of the TCP protocol used by the client. */ 3. Switch to TCP Once the user has entered a message to be sent to another person and the client determines the receiver is TCP capable and this is the first message sent to the receiver, a TCP connection is to be initiated. The first order of business is to use the IP:Port from the online packet and attempt a connect(). 4. The TCP Init Packet After a successful connect(), the TCP Init packet is sent that sends some needed information and basically just says, "Hello." Since we are assuming it is our client sending the first message and performed the connect(), it falls upon our end to start the ball rolling. The following packet is a general TCP Init packet and is sent for ALL types of sockets, Message, Chat, and File. UBYTE Ident; /* Always 0xFF. */ UWORD Version; /* Version of the TCP protocol used. */ UWORD Revision; /* Revision of the TCP protocol version (Mac clients.) */ ULONG TCP_ChatFilePort; /* Port of the client's chat/port listen() socket. This /* is sent only for chat/file connects, otherwise NULL. */ ULONG UIN; /* User's UIN. */ ULONG TCP_MsgIP; /* IP address (LAN External.) */ ULONG TCP_RealIP; /* IP address (LAN Internal.) */ UBYTE TCP_Flag; /* TCP capable flag again, 0x04 = Yes, 0x06 = No. */ ULONG TCP_MsgPort; /* Port of the client's message listen() socket. This is /* sent ONLY for message connects, otherwise NULL. */ After any TCP packet is built, the length of the packet is sent first followed by a second send() of the packet itself. The easiest way to read this from the socket is to first read with a two-byte buffer, then perform a second read with a buffer size equal to the value retrieved in the first read. Don't forget that TCP is 'sizeless', you could only receive half of your packet, or more than one packet at one time, this is why sending the actual packet size first is so important. I leave it as an exercise of the reader how best to read the packets from the socket. 5. The TCP Message Packet No reply will be sent from the remote end to a TCP Init packet. Now, assuming we are sending a simple message, the following message packet is sent containing the actual message typed by our user. ULONG UIN; /* Local UIN. */ UWORD Version; /* TCP protocol version being used. */ UWORD Command; /* Command. Always 0x07EE. See #DEFINEs. */ UWORD X1; /* Always 0x0000. */ ULONG UIN; /* Local UIN. Just in case you missed it the first time. */ UWORD Type; /* Message type. See #DEFINEs. */ UWORD MsgLen; /* Length of message. Be prepared to accept any size. */ char Message[]; /* The message text. */ ULONG TCP_MsgIP; /* LAN External IP. */ ULONG TCP_RealIP; /* LAN Internal IP. */ ULONG TCP_MsgPort; /* Port of the current message socket. */ UBYTE TCP_Flag; /* TCP Capable flag again. */ UWORD TCP_Status; /* The client's status. See #DEFINEs. */ UWORD MsgCommand; /* Message command. Usually 0x0010. See #DEFINEs. */ For a Chat Request packet ONLY, also add the following: UWORD SessionLen; /* Length of the Chat_Session text. */ char Chat_Session[]; /* See the Chat Mode section for description. */ UWORD Chat_RevPort; /* See the Chat Mode section for description. */ UWORD Chat_X2; /* Always 0x0000, padding for port. */ ULONG Chat_Port; /* See the Chat Mode section for description. */ For a FileDirect Request packet ONLY, also add the following: UWORD File_RevPort; /* Always 0x0000 in the message packet. */ UWORD File_X3; /* Always 0x0000, padding for the port. */ UWORD FileNameLen; /* Length of the filename text. */ char File_Name[] /* Name of the file being sent or a file count, '5 files,' if /* more than one file is being sent. */ ULONG File_Size; /* The total size in bytes of all files being sent. */ ULONG File_Port; /* Always 0x00000000 in the message packet. */ Finally, for all packets add the following: ULONG TCP_Sequence; /* The first TCP packet sent after program startup will have the sequence 0xFFFFFFFE. The sequence is then decremented by one for EVERY TCP packet sent AND received regardless of who the sender or receiver is and does not include ACK packets. */ 6. The Message ACK Packet Once the remote client receives the TCP Message packet and the packet was correctly formatted, an ACK packet will be sent. The PC client's message window will not go away and the little face window will continue to spin until this ACK packet is received back from the remote client. The ACK packet is almost exactly the same as the received packet with several important changes. ULONG UIN; /* Local UIN. */ UWORD Version; /* TCP protocol version being used. */ UWORD Command; /* Commands. Always 0x07DA. See #DEFINEs. */ UWORD X1; /* Always 0x0000. */ ULONG UIN; /* Local UIN. Just in case you missed it the first time. */ UWORD Type; /* Message type being ACK'd. See #DEFINEs. */ UWORD MsgLen; /* Length of auto-reply. Be prepared to accept any size. */ char Message[]; /* The auto-reply text. */ ULONG TCP_MsgIP; /* LAN External IP. */ ULONG TCP_RealIP; /* LAN Internal IP. */ ULONG TCP_MsgPort; /* Port of the current message socket. */ UBYTE TCP_Flag; /* TCP Capable flag again. */ UWORD TCP_Status; /* The client's status. See #DEFINEs. */ UWORD MsgCommand; /* Message command. Usually 0x0000. See #DEFINEs. */ For a Chat Request ACK packet ONLY, also add the following: UWORD SessionLen; /* Length of the Chat_Session text. */ char Chat_Session[]; /* See the Chat Mode section for description. */ UWORD Chat_RevPort; /* See the Chat Mode section for description. */ UWORD Chat_X2; /* Always 0x0000, padding for port. */ ULONG Chat_Port; /* See the Chat Mode section for description. */ For a FileDirect Request ACK packet ONLY, also add the following: UWORD File_RevPort; /* Port of the FileDirect listen() socket in network order. */ UWORD File_X3; /* Always 0x0000, padding for the port. */ UWORD FileNameLen; /* Always 0x0001. */ char File_Name[] /* Always 0x00. */ ULONG File_Size; /* Always 0x00000000. */ ULONG File_Port; /* Port of the FileDirect listen() socket in intel order. */ Finally, for all packets add the following: ULONG TCP_Sequence; /* The TCP Sequence of the message being ACK'd. */ Here is a list of changes or items to copy while creating the ACK packet: 1. The Message Command changes from 0x07EE to 0x07DA. 2. The Message Type is copied from the original message packet. 3. Any configured Auto-Reply will be sent with this packet. 4. The Message Command Type changes from 0x0010 to 0x0000. 5. If the receiver refuses the request (Chat or File) the TCP_Status field will be set to 0x0001. 6. The File ports are sent as NULL in the original packet and actually filled in to the ACK packet by the receiver. For Chat port handling, see the Chat Mode description. 7. The Filename of a file send packet is set to NULL for the ACK. 8. The Filesize of a file send packet is set to NULL for the ACK. 9. The TCP Message Sequence is copied from the original message packet. 7. TCP Message Packet Related #DEFINEs /* TCP Commands */ #define TCP_CANCEL 0x07D0 /* 2000 TCP cancel previous file/chat request */ #define TCP_ACK 0x07DA /* 2010 TCP acknowledge message packet */ #define TCP_MESSAGE 0x07EE /* 2030 TCP message */ /* TCP Message Types */ #define MSG_MSG 0x0001 /* 0001 Used to send a normal message */ #define MSG_CHAT 0x0002 /* 0002 Used to initiate a Chat session */ #define MSG_FILE 0x0003 /* 0003 Used to initiate a FileDirect session */ #define MSG_URL 0x0004 /* 0004 Used to send a URL message */ #define MSG_REQ_AUTH 0x0006 /* 0006 Used to request authorization to add to contact list */ #define MSG_DENY_AUTH 0x0007 /* 0007 Used to deny authorization to add to contact list */ #define MSG_GIVE_AUTH 0x0008 /* 0008 Used to grant authorization to add to contact list */ #define MSG_ADDED 0x000C /* 0012 Used to notify that your UIN was added to a contact list */ #define MSG_WEB_PAGER 0x000D /* 0013 Used to receive a web pager message from the white page */ #define MSG_EMAIL_PAGER 0x000E /* 0014 Used to receive an EMail message from UIN@pager.mirabilis.com */ #define MSG_ADDUIN 0x0013 /* 0019 Used to send UINs from one client to another */ #define MSG_GREETING 0x001A /* 0026 Used to send a greeting card */ #define MSG_READAWAY 0x03E8 /* 1000 Used to retrieve a clients Away message */ #define MSG_READOCCUPIED 0x03E9 /* 1001 Used to retrieve a clients Occupied message */ #define MSG_READNA 0x03EA /* 1002 Used to retrieve a clients Not Available msg */ #define MSG_READDND 0x03EB /* 1003 Used to retrieve a clients Do Not Disturb msg*/ #define MSG_READFFC 0x03EC /* 1004 Used to retrieve a clients Free For Chat msg */ #define MSGF_MASS 0x0800 /* 2048 This message was sent to more than one UIN. This is a flag and is OR'd with one of the above */ /* TCP Message Command Types */ #define TCP_MSG_AUTO 0x0000 /* TCP message ACK and Auto-Reply */ #define TCP_MSG_REAL 0x0010 /* TCP message */ #define TCP_MSG_LIST 0x0020 /* TCP message sent to the contact list */ #define TCP_MSG_URGENT 0x0040 /* TCP message sent urgently */ /* The following are flags and are OR'd with the above Command Types */ #define TCP_MSGF_S_INVISIBLE 0x0080 /* The message sender is Invisible */ #define TCP_MSGF_S_AWAY 0x0100 /* The message sender is Away */ #define TCP_MSGF_S_OCCUPIED 0x0200 /* The message sender is Occupied */ #define TCP_MSGF_S_NA 0x0800 /* The message sender is Not Available */ #define TCP_MSGF_S_DND 0x1000 /* The message sender is Do Not Disturb */ /* TCP Message Status' */ #define TCP_STAT_ONLINE 0x0000 #define TCP_STAT_REFUSE 0x0001 #define TCP_STAT_AWAY 0x0004 #define TCP_STAT_OCCUPIED 0x0009 #define TCP_STAT_DND 0x000A #define TCP_STAT_NA 0x000E 8. Other Forms of the TCP Message Packet The TCP Cancel packet is formatted just like a normal message, file, or chat packet. It is sent if the user presses the cancel button after sending the message, file, or chat message and before the receiving end has sent an ACK packet. A cancel packet will have all its fields set to NULL, no text or port information will be sent. The Message Type will be the same as the original message and the Message Command Type will be 0x0010. Also, the TCP Message Sequence will be the same as the original message. The MSG_READxxx Message types are ONLY received when the local client is in that particular mode. The Win95 client can only send one Message Type at a time depending upon the status of the client the message is being read from. What this means is that if your local client is in AWAY status mode, you will ONLY receive a message type of 0x03E8. Your client's response when receiving one of these packets is to merely grab the configured message and send it with the ACK. The PC clients do NOT notify the user when one of these messages are received. 9. Reverse TCP Connections Before going into Chat and File negotiation, one more very important aspect of TCP connection negotiation involves what I call the Reverse TCP connection. This is a UDP packet containing IP and Port information that is sent when client A wants to connect to client B, but for some reason, be it a firewall or whatever, the connect() failed. Here is the breakout of the Reverse TCP connect UDP packet as created by the sender. #define TCP_REQUEST 0x015E UWORD UDP_Ver; /* Always 0x0002, UDP Version. */ UWORD UDP_Cmd; /* 0x015E TCP_REQUEST packet. */ UWORD UDP_Seq; /* UDP packet Sequence. */ ULONG UIN; /* Receiver's UIN. */ ULONG Remote_UIN; /* Remote UIN of requester. */ ULONG IP; /* Remote client's LAN External IP. */ ULONG Port; /* listen() Port in INTEL order to connect() with. */ UBYTE TCP_Flag; /* Always 0x04. TCP Capable flag again. */ ULONG Port2; /* Another Port in INTEL order. Not sure what this is for. */ ULONG Port3; /* listen() Port in INTEL order to connect() with, again. */ UWORD TCP_Ver; /* TCP Protocol version of sender. */ The receiver will receive the above packet with this additional data: ULONG X1; /* Always 0x00000000. Unknown. */ ULONG X2; /* Always 0x00000000. Unknown. */ This is the packet that client A builds and sends to client B via the server using UDP. Once client B receives this packet from the server it will have 2 ULONGs of 0x00000000 appended to the end of the packet making it 8 bytes larger than what the sender sent. I have never seen anything other than all NULLs for these extra bytes at the receiver end. Here is the logic flow: 1. User A types in a message to send to user B. 2. Client A attempts to connect() with client B and fails. 3. Client A builds the TCP_REQUEST packet and sends to the server. 4. Client B receives the TCP_REQUEST packet with client A's IP:Port. 5. Client B attempts to connect() to client A and succeeds. 6. Client B sends the TCP Init packet to client A. 7. Client A sends the message typed by user A in step 1. 8. User B reads the message. The client that performs a successful connect() (client B) sends the TCP Init packet. After that, packet flow resumes as normal just as if client A had actually performed the connect(). The flow is essentially the same for Chat and File connections with a few small changes. In the above example, client B knows the Reverse TCP connect is for an incoming message because client B did not ACCEPT anything from client A. This is different for Chat and File. Like so: 0. User A requests to chat (or send a file) with user B. 1. User B accepts the request of user A and client B sends the necessary IP:Port information along with the Message ACK packet back to client A. 2. Client A attempts a connect() to the supplied IP:Port and fails. Steps 3-6 from above are the same at this point. 7. Client A sends the first actual Chat or File Init packet to client B. 8. Client B responds with the appropriate next packet. In this example, client B knows what to expect because the Chat or File Message packet has already arrived and been accepted by the user. 10. File Direct Protocol After following the above described methods to negotiate, open, and send the TCP Init packet, there are only seven packet types associated with the File Direct Protocol. The first byte of the packets ranges from 0x00 to 0x06. The client sending the file(s) starts with packet 0x00, the receiver replies with packet 0x01, sender sends 0x02, receiver sends 0x03. Packets 0x04 and 0x05 are special packets and can be sent by either client at ANY TIME during the transfer. Packet 0x06 contains the actual 2048 bytes of the file being sent. If more than one file is to be sent, after each file is finished and more files remain, the sender will again send packet 0x02 and the receiver will reply with 0x03. Here are the steps to send two files: S = Sender, R = Receiver. S:0x00 R:0x01 S:0x02 R:0x03 S:0x06 (As many times to transfer the file as needed.) S:0x02 R:0x03 S:0x06 (Again, as many times as necessary.) S:Close the file direct socket. Here are the packet break outs: UBYTE 0x00 Packet. DWORD 0x00000000 X1 Unknown. DWORD Total number of all files to be sent. DWORD Total bytes of all files to be sent. DWORD Sender's speed of transfer. 0x00 to 0x64 where 0x00 = PAUSE and 0x64 = No packet delay. Each count represents a .05 second delay where 0x63 is a .05 second delay, 0x62 is a .10 second delay, 0x61 is a .15 second delay, etc. before sending the next packet. WORD Length of Nick plus NULL. STRING Sender's Nick. --- UBYTE 0x01 Packet. DWORD Receiver's speed. WORD Length of Nick plus NULL. STRING Receiver's Nick. --- UBYTE 0x02 Packet. UBYTE 0x00 X1 Unknown. WORD Length of filename. STRING Name of next file to be sent. WORD Length of text. Always 0x01. STRING Text. Unknown. Always just the NULL. DWORD Size of the next file to be sent. DWORD 0x00000000 X2 Unknown. DWORD Sender's speed. (Yes, again...) --- UBYTE 0x03 Packet. DWORD Size of file on receiver's end. Any number here other than 0x00000000 will cause the sender to skip the specified number of bytes before sending the first packet. Used to implement file transfer resume. DWORD 0x00000000 X1 Unknown. DWORD Receiver's speed. (Yes, again...) --- UBYTE 0x04 Packet. DWORD Possibly the current file number being transfered. Upon receipt of this packet the sender will stop sending the current file and either start on the next file or close the socket. --- UBYTE 0x05 Packet. DWORD Change speed. Can be sent by either client at any time during a file transfer. --- UBYTE 0x06 Packet. ... From 1 to 2048 bytes of the file being transferred. The client should always send 2048 bytes of the file until the final packet. 11. Chat Mode Protocol User to user chat mode or single-chat is much more complicated than anything else in the ICQ protocol. Add in multi-chat and the whole process becomes down right convoluted. It has taken this author several months to work out just how the whole framework of single-chat and multi-chat all meshed together. After much study it finally became clear that the listen() port used was key to understanding the whole process. It turns out that single-chat is actually a striped down multi-chat, not, as was originally thought, multi-chat being a special case of, or built on top of, single-chat. As stated, the listen() port is key as it controls who connects with whom and whether or not the chat mode is single or multi. From here on out, a 'Chat Session' will refer two or more clients connected in such a way that the sent and received text from all members will be seen within a single window. Each chat listen() port controls its own chat session. In other words, each chat session will have exactly one chat listen() port no matter how many users are participating in the chat session. To initiate single-chat mode, a user requests another user to enter chat. The requester's client will create a chat listen() port at this time, however, it will not be passed to the receiver in the message packet. (This is the listen() port used if someone else wants to join this session.) Next, the receiver accepts and the receiver's client opens a new chat session listen() socket and passes its port in the message ACK back to the requester. The requester's client then attempts a connect() on that port. The connection is made, the initial setup packets are passed back and forth and single-chat mode is entered. Here is the chat mode section of the message packet as sent by the requester: UWORD SessionLen; /* Always 0x0001 for single-chat. */ char Chat_Session[]; /* Always 0x00 for single-chat. */ UWORD Chat_RevPort; /* Always 0x0000 in the message packet. */ UWORD Chat_X2; /* Always 0x0000, padding for port. */ ULONG Chat_Port; /* Always 0x0000 in the message packet. */ Here is the chat mode section of the message ACK packet: UWORD SessionLen; /* Always 0x0001 in the ACK packet. */ char Chat_Session[]; /* Always 0x00 in the ACK packet. */ UWORD Chat_RevPort; /* The chat listen() port in network order. */ UWORD Chat_X2; /* Always 0x0000, padding for port. */ ULONG Chat_Port; /* The chat listen() port in intel order. */ The first method to initiate multi-chat mode starts when a user that is already in single-chat session (as described above) requests another user to join the chat session that is already in progress. The initial message packet will contain a comma separated list of all users already in the chat session, i.e. 'User1, User2, User3', and port of the listen() socket that was created when the requester's client first sent/received a chat request message packet. Next, the receiver accepts and the receiver's client opens a chat listen() socket and its port is passed back in the ACK packet. After sending the message ACK packet, the receiver then attempts a connect() on the port passed in the message packet. The connection is made and the initial setup packets are passed back and forth. In these setup packets, the requester's client will pass some information on the other clients in the chat session. This information allows the receiver's client to attempt connect()s with those other users in the chat session. Once all the connections are made and the setup packets are passed between the receiver's client and the other members of the chat session, a multi-chat session is established between all users. Here is the chat mode section of the message packet as sent by the requester: UWORD SessionLen; /* Length of the Chat_Session text. */ char Chat_Session[]; /* Comma separated list of all those in the session. */ UWORD Chat_RevPort; /* Chat listen() port for this session in network order. */ UWORD Chat_X2; /* Always 0x0000, padding for port. */ ULONG Chat_Port; /* Chat listen() port for this session in intel order. */ Here is the chat mode section of the message ACK packet: UWORD SessionLen; /* Always 0x0001 in the ACK packet. */ char Chat_Session[]; /* Always 0x00 in the ACK packet. */ UWORD Chat_RevPort; /* Chat listen() port for this session in network order. */ UWORD Chat_X2; /* Always 0x0000, padding for port. */ ULONG Chat_Port; /* Chat listen() port for this session in intel order. */ The next method used to enter into multi-chat is when a user requests to chat with a receiver that is already in a chat session. In this instance, the chat portion of the message packet will be used in the exact same manner as if initiating a normal single-chat session. The requesting client does not know or care that the receiver is already participating in a chat session. Once the receiver receives the chat request, the user selects the join option and chooses a chat session already in progress. At this point, instead of the receiving client making a new chat listen() socket, it passes the port of the chat listen() socket previously created when the first chat session was initiated. (Now, if the receiving user had NOT chosen the join option, a new listen() socket would be created and a single-chat session would result with the receiver having two chat windows open at once.) When the requesting client receives the ACK packet, it attempts a connect() on that port. After the connect succeeds, the chat initialization packets are passed back and forth. At this point the requesting client learns of the other clients also in the chat session and attempts to connect() with each of the other clients. After all this a multi-chat session is in progress. Finally, the last case is where both the requester and receiver are both in a chat session already. The PC ICQ clients do not allow for the 'merging' of two already in progress chat sessions. If the requesting user selects the Join option, the receiver will not be given the Join option, and if the requester does not select Join, then the receiver is allowed the Join option. Then one of the above three cases will be the resulting method used to initiate a chat session. Here are the chat initialization packets in detail. There are three packets passed during the initialization phase. The client that performed the connect() will send the first packet (with the exception of when a Reverse TCP Connect is used as stated above.) The receiver will respond with the second packet, and the requester sends the third and final packet. At this point the socket becomes a character stream. That portion of the chat mode will be described later. First chat packet: ULONG HandShake; /* Always 0x00000064. ICQ99b uses 0x00000065. */ ULONG HiVersion; /* Negative of the TCP protocol version. V2 = 0xFFFFFFFE */ ULONG UIN; /* Local UIN. */ UWORD NickLen; /* Length of the nick. */ char Nick[]; /* Local nick. */ UWORD RevPort; /* Chat session port in network order. */ ULONG TextColor; /* Text or font color in the form 0x00RRGGBB. */ ULONG BackColor; /* Chat window background color in 0x00RRGGBB form. */ UBYTE X1; /* Always 0x00. */ Second chat packet: ULONG HandShake; /* Always 0x00000064. ICQ99b uses 0x00000065. */ ULONG UIN; /* Local UIN. */ UWORD NickLen; /* Length of the nick. */ char Nick[]; ; /* Local nick. */ ULONG TextColor; /* Text or font color in 0x00RRGGBB form. */ ULONG BackColor; /* Background color in 0x00RRGGBB form. */ UWORD Version; /* Version of TCP protocol used by the client. */ UWORD X1; /* Revision of the TCP protocol, used by Mac clients. */ ULONG Port; /* Chat session port in intel order. */ ULONG IP; /* LAN External. */ ULONG RealIP; /* LAN Internal. */ UBYTE TCP_Flag; /* TCP capable flag again. */ UWORD X2; /* Random, unique chat session identifier, use unknown. */ ULONG FontSize; /* Size of the font. */ ULONG FontFamily; /* Font family? Used for font substitution? */ UWORD FontLen; /* Length of font name text. */ char FontName[]; /* Font name. */ UWORD X3; /* Usually 0x0002. Unknown. */ UBYTE Count; /* For single-chat, always 0x00. When entering a chat session already in progress, this is a count of all other clients in the chat session. */ For single chat mode, this packet ends here with a Count of 0x00. When entering a chat session already in progress, Count will be greater than 0x00. For each other client in the chat session the following data will be appended to the second chat packet: UWORD Version; /* Version of the TCP protocol used by the client. */ UWORD X1; /* Revision of the TCP protocol, used by Mac clients. */ ULONG Port; /* Chat session port in intel order. */ ULONG UIN; /* UIN of the client being referenced. */ ULONG IP; /* LAN External. */ ULONG RealIP; /* LAN Internal. */ UWORD RevPort; /* Chat session port in network order. */ UBYTE TCP_Flag; /* TCP Capable flag. */ UWORD X2; /* Random, unique chat session identifier, use unknown. */ ULONG HandShake; /* Always 0x00000064. ICQ99b uses 0x00000065. */ It should be stated that the above additional data added to the second chat packet will be data that was stored during a previous chat initialization phase and has nothing to do with the client currently being connected to. Upon receipt of this additional data, the client will attempt to connect() with the supplied IP and port. At this point a normal chat initialization phase will begin with each of these additional clients. Also, each of these clients will send an extended second packet containing the data of all the other clients in the current session. Be prepared to ignore the UINs of those clients in which a connection has already been established. Third chat packet: UWORD Version; /* Version of the TCP protocol used by the client. */ UWORD X1; /* Revision of the TCP protocol, used by Mac clients. */ ULONG Port; /* Chat listen() port in intel order. */ ULONG IP; /* LAN External IP. */ ULONG RealIP; /* LAN Internal IP. */ UBYTE TCP_Flag; /* TCP Capable flag again. */ UWORD X2; /* Random, unique chat session identifier, use unknown. */ ULONG FontSize; /* Size of the font. */ ULONG FontFamily; /* Font family? Used for font substitution? */ UWORD FontLen; /* Length of font name. */ char FontName[]; /* Font name. */ UWORD X3; /* Usually 0x0002. Unknown. */ It is unknown what the random number is in the chat packets. However, the PC ICQ clients will only make one number for each chat session. If another, separate, chat session is started, then a new random number will be generated. To be continued...