Re: [TCLCORE] Message vs streams: the full story (AKA it's more complicated than that) Re: Outline of an API for event driven UDP - to be TIPped

[Fredderic U. <mag...@gm...>]

On 15 August 2012 19:26, Trevor Davel (Twylite) <tw...@cr...> wrote:
> On 2012/08/13 05:14 PM, Frédéric Bonnet wrote:
>> http://urchin.earth.li/~twic/Sequenced_Packets_Over_Ordinary_TCP.html
> SOCK_SEQPACKET is still a connected socket, whereas SOCK_DGRAM is a
> connectionless socket.  This is why the POSIX socket API
> (http://pubs.opengroup.org/onlinepubs/007908799/xns/syssocket.h.html)
> distinguishes between recv/recvmsg and send/sendmsg.

That's all low-level implementation stuff.  The whole point of an
abstraction layer, like what's in TCL already, is to make that go away
from the users point of view.  The user shouldn't have to care about
any of that.  They have data they want to send it, they should be able
to send it.  Which system call it leaves by, isn't their concern until
it needs to be.  And at that point, is where dedicated and custom
libraries come in.  Core functionality always involves compromises, in
exchange for keeping it neat, tidy, and flexible.  It's really that
simple.


>>       proc incoming {} {
>>           variable Sock
>>
>>           # Read UDP datagram.
>>           set message [read $Sock]
>>           set peer [fconfigure $Sock -peer]
>>       }
>>       proc respond {peer serviceType} {
>>           variable Sock
>>           fconfigure $Sock -remote $peer
>>           puts $Sock "HTTP/1.1 200 OK\n ..."
>>       }
> Why do you feel the need to shoehorn "receive message with address" and
> "send message to address" into a stateful sequence of
> read/fconfigure/close or fconfigure/puts?  Why is a [close] involved in
> a connectionless, fire-and-forget operation?

Because the channel is holding/caching certain information.  The
channel holding the senders address of a received datagram, allows you
to reply by simply building your response and sending it right back
out the same channel.  That doesn't stop you from changing the remote
address if and when required, and using it very much in a
fire-and-forget mode.  And a very simply wrapper function will allow
you to do just that.


>> - peer-to-peer communication is better isolated: incoming messages have
>> their own channel that preserves message boundaries, and the created
>> channel is writable as well to send back messages
> When does this channel get closed?  Is there some caching mechanism to
> reuse channels when you are receiving a number of datagrams from the
> same source endpoint?

You'd close it manually, when you no longer need it.  Until then, it's
up to you whether you re-use one channel for multiple targets, or open
a new channel per target.

The same choice on the receiving side, is a little more complex.  I'd
like to see this; a listening socket that emits each "unowned"
datagram as a new channel.  In a naive application, it would read the
datagram, send a response if appropriate, and close it.  An
application that wishes to do some minimal authentication, might
choose to leave the channel open, in which case other packets
appearing to be from the same source should be considered "owned" by
that channel, until such time as it gets closed, and would become
available for reading from the stream, one after another.


>> In conclusion I find this code perfectly acceptable and see no
>> compelling argument for specific commands on message-oriented sockets.
>> Of course there are certainly other ways to handle message boundaries,
>> this is just an example on how it could be done. But keep in mind that
>> if we have to create specific support for good old UDP sockets, imagine
>> what SCTP would need. One has to question the universality of Tcl's
>> channel abstraction if such a simple change can't fit.
> Tcl's channel abstraction is just fine.  You're trying to abuse it to
> work with something that isn't a channel.

Of course it is.  A is an abstraction, and as such, like other
channels, it can be re-tuned.  Take an old fashioned TV.  Back in my
youth, I swapped all the channels around on my parents TV one day,
just for fun.  They put it on channel 9, and got channel 12 instead.
They put it on channel 12, and got channel 10.  And so forth.
Whatever makes you think a TCL channel, and a TCP stream, are locked
into being one and the same entity?