CODEWITHSUNDEEP
c++socketsserver
user249806
user249806

Reputation: 299

client server c++ serialization

I am writing some code for a client and server using c++.

I am using boost serialize to serialize an object on the client side and then send it to a server. The server then unserializes the stream and recreates the object. The server then calls the run function of the object. The server then serializes the object and sends it back to the client.

The reason I am doing the above is for instance the client needs to know what files are in the /home/dataIncoming folder on the server.

This is just one simple example

My question is that it seems that for the objects that are serialized I need the same code on the server AND the client. Or how would the server know how to unserialize the object sent.

Thus if I change the server code i need to make sure I also get the code over to the client program.

  1. How do programmers easily solve this problem of duplicate code on the client and the server?

  2. Or is there some way I could serialize so this duplicate code did not need to exist on the client and the server?

  3. or do i simply send a protocol stream over to the server and have the server read in that protocol stream to reconstruct commands to be run and info to be sent back.

It seems easiest to just construct an object on the client side, have it run on the server, then sent it back to the client with results.

Thanks for all your ideas!

Upvotes: 1

Views: 560

Answers (3)

abhishek chattopadhyay
abhishek chattopadhyay

Reputation: 67

Usually the Encoding and Decoding is taken care by the serialization library that you use. (google prorpbuf, nano-pb, boost etc) However Since the encoded from and decoded to classes/structures would be essentially be the same.

So essentially we need the same information on both ends (server and the client) A good idea is to create a dll or an .so for this functional module which when changed can be reflected on both the server and the client, without recompilation.

Upvotes: 1

Steve
Steve

Reputation: 6444

The client and the server have to share data (and the data format), but not the code.

It sounds like your object encapsulates three things:

  1. The data
  2. Some client code
  3. Some server code

A lot of object oriented programming encourages putting data and the code that operates on it into the same object, but that's not always the best solution. Why not separate those things out?

Put your data into a data object and serialize that. The server would have something that operated on that data (presumably some object, not necessarily though) and the client would have something that operated on that data. So, I think you just need to reconsider how your programs are structured.

The architecture you describe also has another downside. If you want to modify the behavior of the server, you have to also update the client. If these concerns were separate, this wouldn't be a problem. The only reason you would have to update both the client and the server is if the data format changes.

Upvotes: 1

mattm
mattm

Reputation: 5949

For generic client server operations:

  1. You compile your code into a library, and use the library on both the client and server.

  2. Your client and server both need to understand the data format. There is no way around this.

  3. You could have a more abstract layer that allows the client to submit the format of new data types, but this abstract layer itself would need to be a data format understood by both the client and server.

It's unclear to me how your example differs (it at all) from the generic case.

Upvotes: 1

Related Questions