General ? - The maximum number of segmented/ split bytes sent over a connection using TCP Protocol?

just wanted to ask what should be the limit of bytes when data is being sent back and forth from server and client, with the great feed back i have go i understand this a bit more, so now the question is what are the size of segmented bytes sent over a connection?

So if i set a buffer size of 3072 bytes to be sent 开发者_运维知识库to the server from the client and the same when sending data from server to client, how are these bytes segmented? and what would be the maximum number of bytes that is sent over a connection so that the bytes dont get segmented?

---

TCP do not guarantee that the number of bytes sent with one send command in the client will be the same number of bytes received in the server with one receive command. TCP is stream based with means that it treats the connection as a stream of bytes and not a stream of messages.

Sending this (two sends):

1. "Hello"
2. "World"

Can be received as:

1. "HelloWorld"

or.

1. "He"
2. "llo"
3. "World"

or any other combination.

Hence you need to be able to detect when one message end and the next begins. The two most common ways is to either use a message header containing the length or a suffix (like a line feed) to detect the end of a message.

Update

TCP should not be used for audio streaming imho. The reason is that TCP guarantees to deliver all sent packets. Hence if TCP detects that a packet didnt arrive it will block all queued packets until the failed one arrives.

When streaming audio it's not important that all packets arrive, one lost packet wont affect the sound too much. It's better to get a little audio loss than to let the audio stream stop completely because the network protocols tries to deliver all packets.

---

There will be a handshake about the MTU size between the one end and the other hand of the connection and according to this size and the protocols wich are used alongside with TCP. There is a amount of data which will be send with one packet.

However the splitting/merging of your data into packets is done by your protocol stack if you do not use a low level API.

---

If you write 3000 bytes to a TCP socket you will receive 3000 bytes at the receiving peer. There is no maximum number of bytes imposed by TCP on the protocol above it. From TCP down to IP down the stack to the protocols below, yes there are limits but your application doesn't have to worry about that. The segmentation and reassambly of ethernet frames into ip datagrams etc... will be take care of behind your back.

However you do have to worry about your protocol at the application level, the one riding on top of TCP. Although TCP will deliver all the 3000 bytes there is no gaurantee that a single call of recv (or whatever the java/php language equivalent is) will return all 3000 bytes at once. You might have to call it several times before all 3000 bytes are read from the socket.

See here for more info:

How to know when you finish receiving a TCP stream?

---

Unless you're writing a TCP protocol wrapper the fact that you're asking this question is a pretty good indication that you're approaching whatever problem you're trying to solve incorrectly. TCP implementations in the languages you specified act as abstractions that should make the answer to this question entirely irrelevant.

See here for my answer to a similar question about packet reassembly: What's the best way to monitor a socket for new data and then process that data?