Dar Scott wrote:

Sorry about that. I was confused about this originally, too. The docs don't help. And it being unlike the TCP comm, confuses it, too.

When you 'open datagram socket', specify a callback. The callback is NOT for completion of the open. That completes immediately. It is for the incoming packets, the responses.

I could have tried for a month of Sundays without guessing that - thank you.


The echo client / server now almost works (i.e. server works all the time, client works to the Rev server, but haven't yet got it to work with the original (non-Rev) server on another machine).

The slight minus is that there is no way to squelch input. The big plus is that you don't loose data.

Some UDP client-server transactions are short-lived. The server sends one datagram back and closes. The client receives one one response datagram and closes. (If this doesn't fit your model, we can get more into it.)

No, there's no problem with the model - I've been working with connectionless protocols including UDP for the best part of 20 years; I'm pretty comfortable with distributed algorithms - the model fits this application very nicely.


It's simply the translation of the standard BSD-socket API into Rev that's confusing me (and the rather less than helpful docs). Fortunately, as usual, the very helpful list members go a long way to make up the the unhelpful docs.

Thank you again
-- Alex.



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.298 / Virus Database: 265.6.4 - Release Date: 22/12/2004

_______________________________________________
use-revolution mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to