I vaguely remember that the discussion went in favor of
keeping it in common denominator rather than making a
comprehensive but large srfi, and let future srfis
to add more features as needed.  So, maybe it's time
to go for a new srfi?

--shiro

>From: Alex Shinn <xxxxxx@gmail.com>
Subject: Re: udp support
Date: Mon, 1 Sep 2014 14:13:57 +0900

> On Mon, Sep 1, 2014 at 1:40 PM, John Cowan <xxxxxx@mercury.ccil.org> wrote:
>
>> Alex Shinn scripsit:
>>
>> > I'm in the process of porting hato to R7RS and was
>> > considering using SRFI 106.
>>
>> I haven't checked lately, but ISTR that SRFI 106 was only meant for TCP.
>>
>
> It describes itself as a general socket API and provides *sock-dgram*.
> If it were meant only for TCP a much simpler design would seem to
> be called for.
>
> Although looking again it seems there's no way to get the remote
> client ip for sockets returned by `socket-accept'?  You can write
> TCP servers without this, but it's pretty important for logging and
> blacklisting, etc.  On the other hand, you can't write a UDP server
> without access to the client address.
>
>> Am I missing something or is there no way to get the
>> > client host or port when receiving udp packets?
>> > Chicken and Racket handle this by returning multiple
>> > values.  Chibi follows C and uses a mutable address
>> > parameter.
>>
>> You might want to look at
>> <http://trac.sacrideo.us/wg/wiki/DatagramChannelsCowan>,
>> which tracks the C API fairly closely.
>>
>
> Thanks, I'll take a closer look at this later.
>
> How can datagram-channel-receive-from truncate when the
> length is longer than requested?  Just about the only thing UDP
> guarantees is that you will never even see a truncated packet.
>
> --
> Alex