I've been struggling with this for a while.
It's not so much a "problem" as it is an approach. I've been working on my client/server socket program and I've reached the point in my planning (which isn't very far in) where I really need to think about how the server will receive commands and respond to them.
Since the server is going to be accepting commands from network clients, interpreting them and (if necessary) running a query on a local SQL server and returning the results to the client the idea of string based commands is not optimal in my opinion, serialized objects sound better.
I was hoping someone could take a minute and give me some feedback on how I plan to approach this.
I know that protocols are all different, and I'm not really asking for that, I have that, but the actual data being transmitted is where I'm stuck.
My idea currently is to have one class for each command type (get data, save data, update data, delete data etc...) and each class would be publicly accessible to both the server and the client. The advantage to this is that the class would only contain data needed to perform that specific task, updating for example would contain a string that held a catalog name, an integer for the row to update or maybe just a datarow and the catalog name. The command type could be transmitted with the object over the socket so that the server doesn't have to determine what type of command it is, it would cypher it out of the socket stream and then send the object to a queue to be processed.
Is there any downside to this approach that anyone can see? Most socket servers examples I've seen are all string based: get a string on the socket, show it in the terminal, send the same data back to the sender, close the socket...boring...and honestly quite useless.
I'd appreciate any feedback on sending objects over the network socket stream. Anything I should be weary about?