Luaancz / Networking

TCP networking samples with C# 5.0
31 stars 10 forks source link

Not standard TCP? #3

Closed Lj-dog closed 2 months ago

Lj-dog commented 2 months ago

Hi Luaancz, I can't use TCP tool to communiate normally. I don't understand how ReadRawMessage() work,and what local variable headerRead,bytesRemaining used for? I want to refer a sample progarm that a TCP server establish connections with multiple TCP clinets.And could communiacte with/disconnect all of/one of them.(Use class TcpListener ,not class Socket) Which Part of the Networking progarm or do you have such a sample progarm I can refer. Thank.

Luaancz commented 2 months ago

Hi, what "TCP tool" are you using? TCP is a protocol based around a bi-directional byte stream; that's all TCP can do on its own. The only thing that comes close to a standard other than that is that a lot of TCP services used to be text-based, so you could use e.g. telnet to talk to the server "directly" (you can still do this with e.g. HTTP or IRC, but not HTTPS; XMPP uses a text-based protocol too, but not quite in the simple plain text request-response of the older protocols).

Both of the current samples use messages on top of those TCP streams (since most of what TCP is actually used for are not streams), and use a binary protocol, rather than a text-based one.

The first sample uses one of the simplest mechanisms to create an echo server - the request message is prefixed with a fixed-length 4B length (so the receiver can know where the message actually ends; though note that it uses native endianness, so it's not actually "cross-platform" - this wasn't much of a problem when .NET only really existed on little endian machines, but is today :)). The message itself is UTF-8 encoded text. The server responds by repeating the same message and closes the connection when it's done sending. This is actually similar to how very basic HTTP works, except that HTTP is a text-based protocol.

The second sample is more practical; it keeps the connection between the client and server open and allows you to send and receive different kinds of messages. The messages are again length-prefixed, but also contain a message ID, allowing you to distinguish between different messages. The client "logs in" by providing a username, and is connected to a shared "chat room", where the clients can talk to each other with server broadcasting their messages (and system messages) appropriately. You can easily extend this with new message types, add things like authentication and permissions etc. This is similar to how very basic IRC works, though again, IRC is a text-based protocol.

You can use the second sample as a limited starting point for what you're trying to do, but keep in mind the protocol on top of TCP is custom, so you have to use your own tools to work with it (though it's also so simple it's easy enough to work with in something like Wireshark). Note that these are just samples to show how to start - they're definitely not production ready, they don't handle most error cases that occur in TCP communication and as noted above, they use machine-specific number encoding, which is definitely wrong (I should probably fix that :) in short, replace BitConverter with BinaryPrimitives and stick to one endianness).

Length-prefixed binary messages are very handy for computers to communicate with; not so much for humans to interact directly. If you want to be able to communicate with the server using something like telnet, you'd need to use a different approach - the most common one being reading text lines at a time and parsing them for content. A message could then look something like HELLO Lj-dog\r\n, easy to work with for humans (and logging). I'm not planning on making a sample of that kind of client-server communication, though; there are many advantages to that kind of protocol, but also plenty of disadvantages. It works fairly well for high-latency, low-throughput systems with implicit trust, but it comes with plenty of costs, especially if you don't have the option of layering the protocol with something providing compression and encryption.

Lj-dog commented 2 months ago

Thanks,some words is too technical for me.But I get it.The project is short connection and use custom protocol on top of TCP,rather than long connecntion and standard TCP(or call it "naked TCP").