Please suggest other ways of communicating between server & client

Question

I'm writing a TCP chat server ( programming language does not mather ). It's a school project for my nephew, so it won't be released, and all questions I'm asking are just for my knowledge :). . Some of the things it will support:

• chatting between users ( doh ), it will be multithreaded
• sending each other files

I know I could easily get away with all the stuff above if I go with serialization, and just send objects from client to server and back. But, if I do that, it will be limited to a specific programming language ( meaning clients written in other programming languages may not be able to deserialize the objects ). What would be the way to go so that other clients written in other languages could be supported?

One way to go, off the top of my head, would be to go in this direction: the server & the client communicate by sending messages & chunks ( in lieu of other names ). Here's what I mean by this:

• every time the client/server wants to send something ( text message or file ) it will first send a simple text message ( newline terminated ) with the number of the chunks it will send. Example:

  command 4,20,30,40,50

Where command would be something like instant-message or file,4 would be the number of chunks to be sent, 20 would be the size in bytes of the first chunk, 30 of the 2nd, and so forth.

• after the message was sent, the client/server will start sending chunks ( of sizes mentioned in the sent message ).

What do you think about implementing the client/server communication this way? What better options are there?

Answer 1

Silly question: Why not use TELNET protocol over TCP/IP for the chat stream, and something like FTP over TCP/IP for file transfers?

Answer 2

A pretty typical solution here is Web Services using SOAP.

Answer 3

I might pass XML between the clients; that'd work.

For passing files, perhaps just pass a byte buffer; only problem there is if you're going between high endian and low endian machines, I think.

Answer 4

That sounds fine, basically you need to define a message header (as you have done) so that a receiver will know how many bytes to read for each message.

I suggest placing a message size as the first parameter instead of a variable-length command string. That way there is no ambiguity in case the command happens to arrive across 2 separate TCP packets.

Answer 5

What you say about serialization isn't true. You can use a cross-platform serialization protocol, like protocol buffers. This will make your life easier and save you from implementing your own communication protocol. In my opinion it will be better to find an existing protocol and implement this instead of trying to make your own. Something as simple as xmodem could do.

Also to avoid client software having to act both as server and as client (meaning having to solve peer identification issues), you could have all clients communicating through a centralized server.