-2

This is a question I've had on my mind for ages.

Here's my scenario. A Chat server hosted on a laptop connected to the network via Wireless. Now each client is always requesting and sending data the Server must parse. Average packets look something like:

REQ_RM_LST|InfoHere

Or

CLI_LIST|NameHere|NameHere|NameHere|NameHere|NameHere|NameHere|NameHere

Will this ever mess up the Server? As in, cause packet loss, data loss, packets/requests not even being parsed? If so, how many clients would be connected and sending similar data with varying lengths in order to generate these issues?

Thanks!

4

1 回答 1

4

Average packets look something like:

No they don't; for two reasons:

  • TCP only sees binary, not text - and there are dozens (hundreds?) of ways of encoding that text as binary; when discussing sockets, the binary is what matters
  • TCP is a stream, not a series of packets. At the network layer, "packets" are a unit of data, but you don't see that at the application layer - you only see a stream. So if you haven't defined some kind of framing protocol into your stream, expect pain

Will this ever mess up the Server?

No; why would it?

As in, cause packet loss,

At the network layer, that is down to the TCP implementation; as long as your NIC/drivers are sane. At the application layer: that is down to your code.

data loss, packets/requests not even being parsed?

Again, down to your code

If so, how many clients would be connected and sending similar data with varying lengths in order to generate these issues?

That isn't a factor of the number of clients; if your code has bugs, then it has bugs regardless of how many clients are connected. I have socket servers running with many tens of thousands of connected clients for extended periods - not a problem. The "realtime updates" socket server for the Stack Exchange network currently has 126,815 connected sockets (spread over a few servers, but that is mainly for deployment resiliance - we've had very high numbers even on a single server instance) - and is written using C# / .NET sockets.

The single most common mistake people make in sockets is expecting the sender to do:

Write({8 bytes});
...
Write({12 bytes});
...
Write({8 bytes});

and expecting the receiver to get 8, 12, 8 bytes. That is not what happens. It is just a stream. The receiver could get all 28 bytes in one go, or could get 2, 10, 1, 1, 14 bytes. Which is why you need to write some kind of framing protocol. For text-based protocols this is commonly "read until you get a sentinel value, for example a byte that represents a newline". For binary-based protocols (where sentinel values make no sense) this is commonly a length-prefix, for example "the first 4 bytes are a little-endian encoded 32-bit integer that represents the length of the subsequent payload" (there are plenty of other encoding schemes possible, note).

For more info, read http://marcgravell.blogspot.com/2013/02/how-many-ways-can-you-mess-up-io.html

于 2013-05-29T08:41:11.397 回答