ICB Protocol

Last Modified: Sat Aug 4 01:19:36 PDT 2001 by falcon@icb.net

Basic Packet Layout:

The basic unit ICB clients and server communicate with is a packet with the following layout:

LTd

"L" is the length of the packet in bytes. "L" is a single byte, thus the packet length is limited to 0 to 255 bytes. It does not include the L byte, but does include the Packet Type byte. The protocol (and the chime server) does not require the data in the packet to be null-terminated, but some older (poorly implemented) clients and servers do. If you *do* send the null, you must include it in your length byte.
Proposed extension: if L is 0, the packet is part of an extended packet. The packet should be treated as if L was 255 and the next packet received from the sender should be appended to this packet.

"T" is the ICB type that the packet is to classified as. It is a single byte. See "ICB Packet Types" for the list of possible types.

"d" is the data contained in the packet. It can contain any valid ASCII data, and can be up to 253 bytes in length if you null-terminate (as recommended above), or 254 bytes in length if not.

ICB Packet Types

The data in a packet is often seperated into what I will call fields. The fields are data separated by ASCII ^A (\001). If a field is optional, it (and any fields after it) can merely be left out of the packet.

'a' : Login packet

Client to Server

Thus the ICB Login Packet has the following layout:

aLoginid^ANickname^ADefaultGroup^ACommand^APassword^AGroupStatus^AProtocolLevel

Server to Client

Thus the ICB Login OK Packet has the following layout:

a

'b' : Open Message packet

Client to Server

Thus the ICB Open Packet has the following layout:

bMessageText

Server to Client

Thus the ICB Open Packet has the following layout:

bNickname^AMessageText

'c' : Personal Message Packet

Client to Server

Not valid. Clients cannot send servers Personal Message packets.

Server to Client

Thus the ICB Personal Message Packet has the following layout:

cNickname^AMessageText

'd' : Status Message Packet

Client to Server

Not valid. Clients cannot send servers Status Messazge packets.

Server to Client

Thus the ICB Status Message Packet has the following layout:

dCategory^AMessageText

'e' : Error Message Packet

Client to Server

Not valid. Clients cannot send servers Error Message packets.

Server to Client

Thus the ICB Error Message Packet has the following layout:

eMessageText

'f' : Important Message Packet

Client to Server

Not valid. Clients cannot send servers Important Message packets.

Server to Client

Thus the ICB Important Message Packet has the following layout:

fCategory^AMessageText

'g' : Exit Packet

Client to Server

Not valid. Clients cannot send servers Exit Message packets.

Server to Client

Thus the ICB Exit Message Packet has the following layout:

g

'h' : Command Packet

Client to Server

Thus the ICB Command Packet has the following layout:

hCommand^AArguments^AMessageID

Server to Client

Not valid. Servers cannot send clients Command packets.

'i' : Command Output Packet

Client to Server

Not valid. Clients cannot send servers Command Output packets.

Server to Client

Thus the ICB Command Output Packet has the following layout:

iOutputType^AOutput^AOutput...^AMessageID

'j' : Protocol Packet

Client to Server

Thus the ICB Protocol Packet has the following layout:

jProtoLevel^AHostID^AClientID

Server to Client

Thus the ICB Protocol Packet has the following layout:

jProtoLevel^AHostID^AServerID

'k' : Beep Packet

Client to Server

Not valid. Clients cannot send servers Beep packets.

Server to Client

Thus the ICB Beep Packet has the following layout:

kNickname

'l' : Ping Packet

Client to Server

Thus the ICB Ping Packet has the following layout:

lMessageID

Server to Client

Thus the ICB Ping Packet has the following layout:

lMessageID

'm' : Pong Packet

Client to Server

Thus the ICB Pong Packet has the following layout:

mMessageID

Server to Client

Thus the ICB Pong Packet has the following layout:

mMessageID

'n' : No-op Packet

Client to Server

Thus the ICB Pong Packet has the following layout:

n

The Life Cycle of an ICB session

The steps a typical ICB session goes thru is as follows:

Further Information on Various Packet Types

Login Packet

The client can send one and only one Login Packet to the server.

Message IDs in Command and Command Output

If the client sends the server a Command packet that contains a Message ID, all output sent from the server to the client in response to that Command should place the same Message ID in the Command output packet.

Ping and Pong

When one side receives a Ping packet, it sends a Pong packet back in response. As with Command/Command Output, if the Ping contains a Message ID, the Pong packet should contain the same ID.

Command Output Types

There are various Command Output Types. The ones currently defined are:

Protocol Negotiation

There is currently no way for the client and server to negotiate a protocol level. A proposed method for implementing it will be added here at a later date.