Home/ Questions/Q 6042857
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T06:50:11+00:00

I am programming a Client/Server application for my project in C++. The whole application

  • 0

I am programming a Client/Server application for my project in C++. The whole application protocol was given or discussed by the working group. The main idea is that we have 3 protocols.

  1. Text-protocol: send and receive some information in string format between client and server.
  2. Binary-protocol: client sends continiously some status data to server.
  3. Binary-protocol: client sends continiously some data like sound/video/images/text

All Protocols should run on different ports.
I implemented a Socket-Class, which is responsible to create and listen socket, accept the connection from the client. Also there is a function to receive/send string-based data and receive/send binary-based data.

In the next step I wanted to define 3 Classes. Each of them should be responsible for creating one socket in new Thread and responsible for the protocol, which was defined for that port (s. 1-3). So at the end I will get 3 Sockets (1 Socket for one Port).

My question is, if I think in right direction? Maybe you can recommend my some design patterns for using different application protocols. It would be great if you can recommend me some projects or code, which can be similar with my project.

Thank you.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You should decouple your socket class from the 3 protocol handlers – don’t have methods for both text and binary data handling on the Socket or you unintentionally encourage people to mix and match data types over the same socket, which is clearly not what you want.

    Your socket should provide simple connect/disconnect, data transmission and receipt functionality, and the decoding and encoding of sent/received data is then done in a different object, likely picked from 3 new classes (one per protocol).

    On a general note, I question the use of text data. It’s inefficient compared to virtually any serialization library you could name. You could be trading a little extra debuggability for a lot of hard-written data parsing and error checking code, and concomitant CPU cycle wastage. If the text data is fairly simple (not actually structured like XML, say) then this is less of a concern.

    Protocol 2. might be implementable using UDP rather than TCP, if the status info is not mission-critical. That’s one less connection you’d have to manage.

    • 0