TCP/IP packet run-together-ing

I don't know exactly where to put this... So I'll play it safe and put it here. It's more networking related than C or C++.

I'm writing a chat program for Flashdaddee. It uses TCP/IP to connect and send packets both ways. Every packet must be at most 500 bytes.


My problem is that there are some places where packets run together. My send command sends the exact length of bytes needed, and my receive command receives up to 500 bytes, maximum.

Most of the time, one packet is received as a whole, and the client program processes it like normal. But when I send one packet after another, with 2 seperate send commands, they are both received as one packet. The one sent second can be seen right after the first one.

Can anyone here explain why this happens? Would it be practical to wait for acknowledgement from the receiving side each time a packet is sent? Is there another, simpler way I haven't thought of?

It's part of the TCP specification. It's a reliable byte protocol, it is not message based. The 'byte bunching' is actually neccesary for decent speed with things like telnet, in which multiple keypresses are sent in one packet to reduce the per packet overhead of TCP.

You can get around this by having messages have their length as the first part of their data. That is, dedicate the first 2 bytes (You need two bytes, if your message sizes can vary by 1 byte and you need more than 256 bytes). Then when you read messages, read the first two bytes first to find the length of the message, and then read the next length bytes more (if available). You know that, after reading length bytes, the next 2 bytes will be the size of the next message.

Oh, I see. "It's not a bug, it's a feature."

What if I terminate every message with one unique byte? Given that I don't use that packet format for data files.

Another question: What amount of bytes is the maximum sent before I have to check the return values of the send and receive functions to make sure all bytes were sent?

Terminating the messages with a unique byte will work.

In order for the software to be reliable, you are going to have to keep on checking how result of send. It's possible, that in highly pathological cases, a send of one byte could block.

I don't know if you've ever seen python before (even if not, you may be able to follow the little mysocket class defined in section 3) , but wrapping the socket into something that you can guarentee will always send as much as you tell it to is nice.

http://www.amk.ca/python/howto/sockets/

Basically, upon a send with your socket, you try to send the amount with the socket you are wrapping, then, if that doesn't send everything, you send the remainging portion again, and again, etc.

If it turns out the network code is too slow, you can the slow portions of it.

[EMOBA] recommended python to me earilier for doing fast and dirty server applications. The program I'm writing now already has encapsulated sockets, so fixing the problem shouldn't be too difficult.

One more question: Is it possible to compile python? Flashdaddee needs a GUI client, and I'm thinking of using python's (semi)built in tkinter GUI capabilities. But I want to be able to distribute binaries for those who don't want to download the python interpreter.

[url=http://pw1.netcom.com/~jsnader/]This book does a good job of explaining TCP/IP messaging. I doubt you want to buy it... but you can download the source code from this web site (the authors homepage). It should give you a good idea on how to do things.

I am actually in the process of making a GUI application in python with Tkinter. It can be compiled into a binary that doesn't require a python installation on the user's part. So the user can download and double click the exe, and everything works. The package to be distributed is rather large (I think 4 MB uncompressed with Tkinter and a few other libraries).

eh... 4 MB? What about compressed? Flashdaddee has a 2 MB limit.

It probably hovers right around there, unfortunetely :(.

You could possibly get it hosted elsewhere, or just not write it in Python.