简体   繁体   中英

Unified communication

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

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).

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM