Dennis Windisch wrote: >> I guess you also mean that the clients are sending to different ports. >> Is there no way to direct the messages to a single port and demultiplex >> at application level? Are the messages undistinguishable when they >> would arrive on the same socket? > In my current implementation the clients send to the same port (resulting > in one socket on the server side). In the final implementation each > message would contain an ID (mostly an integer) describing which client > send the message. > > Maybe it's better if I just describe what I want to do: > On the server (running on RTAI/RTnet) should be running a periodic task. > This task should receive every period messages from the two clients > (running on VxWorks). Then the task performs some operations and sends > back the clients appropriate messages back. This should all happen every > period and - of course - in realtime.
I see no need for (RT-)select so far. > >> The last resort is to create multiple threads and synchronise them when >> required. Admittedly, this /can/ be even more inefficient than a >> potential select/poll RT-variant (but it allows prioritisation). So, I >> would rather try to avoid scenarios where events can arrive in an >> unordered way on multiple channels for a single consumer. > It is thought that all clients send their messages to the server every > period. I didn't spend much concern about the order, I admit, since each > message would be "labeled", containing the senders ID. But writing this, > it also seems a bit undeterministic to me. A better (more deterministic) > way would be: Server-Task waits for message of Client 1, reads it and > saves it, THEN Server-Task waits for message of Client 2, and also reads > and saves it, after this the server task performs the operations needed. This only works if the transmission order of both clients are strictly deterministic, which also means that they had to be synchronised in some way. Is this the case? Actually, I do not see the need for such a strict ordering in your described scenario. > > If I do it this way, I also could use two sockets server-side (two > ports), on for communication with client 1 only and one for communication > with client 2 only. > Would this be a better solution? Or am I overlooking something important > when I would solve the problem this way? (Using this solution I of course > wouldn't need a select function anymore, since one socket only receives > one message per period). > I would still vote for a single socket and application-level demux. Jan
signature.asc
Description: OpenPGP digital signature
