On 30/08/12 11:29, Joe English wrote:
Blocking receive is useful in a few cases.  Main examples
I can think of are simple RPC clients.  In some cases it
may be convenient to use blocking receive in RPC servers
as well.
Personally I could live without blocking receive, but I
wouldn't necessarily argue for its exclusion.  It's
occasionally handy.

Upon reflection, I consider blocking receive (if it is useful) is best implemented externally to the UDP protocol, as it is extrinsic to UDP.

The evidence you tender for its utility is necessarily contrived, as RPC is a protocol layered upon UDP, and is not UDP itself.  I would argue that the appropriate place for considering how to block, pending the receipt of a datagram, to be consumed by a protocol handler is in the protocol (or protocol handler) which requires the blocking.

In most of my network programming, I have been put to task to embed code which is more cleanly written as if it were in its own thread of control into a multiple event source context.  The coronet suite is an example of the effort required to go that way, it is considerable.  It wasn't really possible to hijack code which was written to assume it could block, so it could cooperate with other code, before [::coroutine] and coronet.

I think that the problem of writing a system such as you posit, above, is not made simpler by glossing decisions needed to get the hypothetical RPC system to play nicely with other components which might also operate under the (sometimes useful) illusion that they are the main processing thread.

I see no reason, a-priori, to suppose that something like coronet, written expressly and generally to provide the illusion of blocking, and which was implemented extrinsically to UDP and perhaps to RPC, would not better serve the application you posit.

I guess what I'm concerned about is the implementation of policy decisions about the implementation of higher level protocols in a low level protocol like UDP, because (a) I'm not comfortable that I can make such decisions in a fully general way, given only hypothetical use-cases, (b) even if I were comfortable, I think would choose a different place to implement those decisions, as the UDP protocol itself seems silent in this context.