SUBJECT This is description of a low level datagram oriented protocol used in LanChat (http://sourceforge.net/projects/vnlanchat) and in several other applications I've written. This protocol (it has no special name yet) supports reliable datagram delivery. TRANSPORT This is a datagram oriented protocol. Currently, UDP protocol is used to transport datagrams between hosts over network. But this protocol is not limited to usage of UDP as transport. DATAGRAM FORMAT Data is sent in form of datagrams. Every datagram is comprised of a header, datagram body, and a trailer. Header consists of two fields: a) Datagram type: one byte, may have one of three following values: 1) 0x7B - data message, requires acknowledgement datagram. 2) 0x7C - data message, does not require any acknowledgement. 3) 0x7D - acknowledgement message. b) Datagram unique ID: 32bit big endian (you probably will need to use htonl to manage that) integer (four bytes). This field is only required when datagram is of type 0x7B or 0x7D. Datagram ID is useful for sending the acknowledgement. You should fill this field when sending datagrams, so that it remains unique among all datagrams you send to certain host for some interval of time. I call this 'Datagram ID memory interval', and I set this to 1 min. Datagram body is a plain text string without ending zero symbol. Trailer consists of one field - CRC for the datagram. The CRC is a 32bit big endian integer (four bytes). It is computed through message header and message body, and it is stored right after them. Sample CRC function implementation is given below. #define CRC32_POLY 0x04C11DB7 static unsigned CRC32(const void *buf, int count) { unsigned sum = 0; int i, j, flag, b; unsigned char c; for (i = 0; i <= count; ++i) { c = i < count? ((const unsigned char *)buf)[i]: 0; for (j = 7; j >= 0; --j) { b = (c & (1 << j)) != 0; flag = (sum & 0x80000000) != 0; sum = (sum << 1) | b; if (flag) sum ^= CRC32_POLY; } } return sum; } RELIABLE DELIVERY This is done by sending acknowledgement datagram for every datagram received which required it (0x7B, see datagram types). Each time such a datagram is received the sender must be replied to by a datagram of type 0x7D with the same unique ID. In case this was not done in a while (I've set it to 2 sec.) the sender assumes the datagram was lost (e.g. because of high network load) and it resends the datagram again. This may be repeating several times. After some time has passed (15 sec. currently) and no acknowledgement was received the sender reports the error. In turn, the receiver may eventually get the same datagram several times. It must acknowledge each one, but probably should not transfer the message several times to the application level :). Sla/n agus beannacht leat! Vaclav.