View topic - Design question: changing pulse value from server side ?

Design question: changing pulse value from server side ?

For discussion of realtime and/or embedded programming.

Design question: changing pulse value from server side ?

Postby _KB_ » Wed Mar 13, 2019 8:52 am

Hi,

I have a design dilemma.

I have 3 processes, one server (S) and two clients (C1) (C2) :

(C1) ------(MsgSend)----> (S) <-----(MsgSend)---- (C2)

Each client MsgSend the server in order to read data. Processing from server side is often fast, the
client can blocked until the server MsgReply it.
From time to time a client requests data that need a long time processing (from 1 to 10 seconds). Call it a "long request".

In this case the client MsgSend the server which replies : "OK I'll do this and report to you when I'm done".
To achieve that, the client first MsgSend a "cookie", to the server (a struct sigevent, encapsulated in a message). It is a pulse for the client, but an opaque event for the server.
The server saves the receive id (rcvid) and the cookie and MsgReply to unblock the client. When it finishes its processing, it MsgDeliverEvent(rcvid, cookie) to the client.
The client which was sending other requests to the server meanwhile, knows that the server just finished the "long request".

(C1) ------(MsgSend (cookie))------------------> (S) : "long request" here a cookie to warn me with a sigevent I chose when you're done
(C1) <-----(MsgReply (acknowledge))------------- (S) : "OK I'll do this and report to you when I'm done"

(responding to other requests from C1 & C2)

(C1) <-----(MsgDeliverEvent (rcvid, cookie))---- (S) : "I'm done"

So far so good.

Now my dilemma.

SOLUTION A:

The result of the "long request" is basically : OK or ERROR CODE (errno).
It could just fit a pulse 32-bit value.
Should it be considered bad design to change the pulse value before MsgDeliver the server?

Code: Select all
typedef struct {
  uint16_t type; /**< all message type shall implement a type to distinguish them */
  struct sigevent event; /**< event type sent by a client to a server for asynchronous messages (e.g. pulses, signal) */
} cookie_t;


typedef union {
  uint16_t type;
  struct _pulse pulse;
  struct clientMsg msg;
  cookie_t cookie;
}clientmsg_t;

// clientmsg_t msg
msg.cookie.event.sigev_value.sival_int = requuest_response; // smells bad design...
MsgDeliverEvent(rcvid, &msg.cookie.event);


The client doesn't know and doesn't care what's the event sent back to the server (could be a pulse, a signal, a new thread, whatever the client encapsulated).
However the code above works. The client get a pulse code and the value is the result of the "long request".

SOLUTION B:

If this is bad design, another way is to MsgDeliver the client without modifying the pulse value.
When the client receives the pulse, it then MsgSend the server in order to get the result of the "long request".

(C1) ------(MsgSend (cookie))------------------> (S) : "long request" here a cookie to warn me with a sigevent I chose when you're done
(C1) <-----(MsgReply (acknowledge))------------- (S) : "OK I'll do this and report to you when I'm done"

(responding to other requests from C1 & C2)

(C1) <-----(MsgDeliverEvent (rcvid, cookie))---- (S) : "I'm done"
(C1) ------(MsgSend)-------------------------------> (S) : "give me the results of long request"
(C1) <-----(MsgReply)------------------------------- (S) : "Here you go"

So is it A or B ?
Any clarification and/or suggestions are welcome.

Thanks.

KB
_KB_
Active Member
 
Posts: 35
Joined: Mon Oct 15, 2012 6:36 pm

Return to Realtime and Embedded

Who is online

Users browsing this forum: No registered users and 1 guest