Hi all,

long time no see
Well dont think anyone remembers me around here anymore, anyway im around just not posting, been busy...

Onto my question
Been working with UDP and stuff works as I want it to, trying to move to TCP got into "small" problem. TCP sees its connections as streams, meaning when u send 2 packets they might not arrive as 2 packets but rather as 1 combined. UDP sends packets as u construct them.

So, a bit of phyton, server side:


And client:


So the problem is obvius (or not ) the server recived packets 3,4,5 as 1 combined packet even tough client sent them separately. Or should I say they were created separately but TCP/IP stack waited, packed 3 into one and sent them as one.

Anyone know a "trick" to make TCP behave as UDP on that matter; to send packets one by one?

you could have a look at enet:
http://enet.bespin.org/

it's open source and they have added a "layer" on top of UDP to make it act like TCP for the user, check the "features and architecture" side.
I'm afraid i can't help you any more then that, but there are some multiplayer professionals around here, just be patient and you might get a better answer.

Thx Schoko but i know all corners of Enet on top of my head

As U said it, Enet "emulates" TCP (and does more) but is still UDP. Using it is great, still havent found a better free code on Internet than Enet. Hat down to guys that made it available to everyone.

Basically the problem is very simple to solve. Normally you don't just use TCP but you add an application layer on top of it. That means you have to define your own rules for messages. For example, you could send an integer from the client to the server (always 4 bytes long) that defines the length of the string to read from the stream. Then you read the amount of bytes defined by the first integer and go over to the next message which follows the same format. Alternatively, you could use null terminated strings or whatever you like.

Yea, i know that too
But it still doesnt send packets as they are generated, and that can generate unwanted latency. In FPS (even tough u would use UDP for that, dont want to be screwd up by TCP retransmission) this would generate unwated delay and that would be variable because u never know when will TCP send your data as 1 packet or will it sit and wait for 3 of your "send commands" and send them as 1 packet...
Another "problem" I have is with MMO game(s), clients waiting and sending 3x data in 1 packet generates unwanted overhead of delimiting/unpacking at reciver and teoreticaly if all clients wait and send 3 of generated packets in 1 TCP they generate more data to hold at once at reciver end (server) and if you have 1000 clients on a server...

Anyway just wanted to know if someone knows any trick to get rid of this TCP "feature" would be great

Depending on the API you use, TCP connections can be configured to send data immediately. However, this generates more data to be sent (think of the underlying protocol's headers). Also due to TCP's reliability it may take longer to send multiple data packets than to send one bigger packet after a small timeout. Like you said yourself, UDP is better suited for updating game states.

However, I do not recommend to turn off buffering because it will consume more resources.