Home/ Questions/Q 827409
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T03:34:11+00:00

I’m writing a TCP chat server ( programming language does not mather ). It’s

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0