0

I am wondering how should I set up interprocess unified communication in better way than I do now. Client process sends a lot of messages of different sort to the server process. Messages like... I have done some work[what],I started at [time], ended at[time]. or state, progress even command messages.

example message: From:Process1;StartedAt|12:12:12;EndedAt|12:45:56;DoneUnit:51

Server parser split string by semicolon. From first part reads from who was message sent. from second and third part it reads times and from last how much work it did. When I add another info at the end of message

ex. From:Process1;StartedAt|12:12:12;EndedAt|12:45:56;DoneUnit:51;Source:tableT I have to rewrite the server parser as well.

Server tries to parse received message using my own parse function. Every message has its own format. So parser know how should message look. But if I change the format on client I have to change it on server as well. It does not seems to be very efficient way.

For that reason I ask you a question. How should this communication get better or is there any different approach how to store the format for client and server on one place?

I use c# .net 3.5(Must be this version)

Thank you for reply

user3716282
  • 25
  • 5
  • You've got two separate questions here: one is about encryption, the other is about your message format. You might be advised to separate the two so that the answers you get are more concise/useful. Regarding the message details, I don't think that there's enough information in the question to usefully answer it. Regarding encryption: if you are sending information over a network, it is visible. If you don't want it to be read, you need to encrypt it. – Dan Puzey Aug 18 '14 at 08:15

1 Answers1

1

The obvious solution to your problem would be to not write the parsing code yourself.

If you create a class that can be serialized, you can send the serialized version of the class over the wire and deserialize at the other end. That means the message class can be shared between both applications, and the parsing code is trivial. Depending on your requirements, you can use various serializers: Xml or JSON would be verbose but human-readable, or the binary serializer would be more efficient in terms of bandwidth (but harder to debug or monitor over-the-wire).

Dan Puzey
  • 33,626
  • 4
  • 73
  • 96