[usocket-devel] Re: UDP support in usocket, ideas explained

[Chun Tian (binghe)]

On Feb 2, 2008, at 7:25 PM, Erik Huelsmann wrote:

>>>
>>> Looking further, you'll find there are functions defined for  
>>> creating
>>> stream and stream-server objects. A function like that should be
>>> created for UDP sockets.
>>
>> I see a function USOCKET::MAKE-SOCKET, no one calls this internal
>> function:
>>
>> (defun make-socket (&key socket)
>>   "Create a usocket socket type from implementation specific socket."
>>   (unless socket
>>     (error 'invalid-socket))
>>   (make-stream-socket :socket socket))
>>
>> What's is this function created for? Should this function be extended
>> to support DATAGRAM-SOCKET?
>
> I'll have to look this one up. I'll come back to it later today.
>
>>> I think it's only sane to extend WAIT-FOR-INPUT to apply to UDP
>>> sockets as well as any of the currently supported sockets. The
>>> LispWorks variant of this function (for win32) is still on my  
>>> laptop.
>>> I'll try to finish it up soon, so that you can all start testing it.
>>
>> I've read the WAIT-FOR-INPUT and WAIT-FOR-INPUT-INTERNAL in
>> lispworks.lisp.
>>
>> Can this function (not win32) be used for UDP socket directly? I
>> didn't see any TCP-specific code... under my networking knowledge:)
>> Could you tell something about this? Thanks.
>
> Yes. I'm guessing it internally works with the select() or poll()
> function calls, which is exactly what we want to use.
>
>>>
>>> I propose we implement recv()/recvfrom() as one function:
>>> SOCKET-RECEIVE. I think we shouldn't bother implementing recv() and
>>> recvfrom() as separate interfaces: I think we should return the
>>> recvfrom-address field as the second return value of SOCKET-RECEIVE.
>>>
>>> I also propose we implement send()/sendto() as one function:
>>> SOCKET-SEND. I think we should provide the sendto address as an
>>> optional parameter to the SOCKET-SEND function.
>>>
>>> Also, I think the function should check for connected-ness of the
>>> datagram socket. If the sendto address is specified on a connected
>>> socket AND the address specified is unequal to the connected  
>>> address,
>>> the function should error.
>>
>> I agree. And seems SOCKET-SEND and SOCKET-RECEIVE will be a general
>> method for both TCP and UDP (and others, if exist).
>>
>> Otherwise, a stream-socket may be used for UDP too, though UDP is not
>> a connected socket.
>
> Well, yes and no. From the above remark, I think we need to establish
> some terminology.
>
> All TCP sockets (when ready for sending/receiving information) are  
> connected.
>
> This is not true for UDP sockets: UDP sockets can send/receive
> information both in connected and unconnected states. [A socket is
> connected after connect() has been succesfully called on the socket.]
> When sending/receiving information from an unconnected socket, you
> need to use recvfrom()/sendto(). For connected sockets, you can use
> send()/recv() and on Unix you can even use write()/read().
>
> So, while TCP is a stream protocol, UDP is not. While TCP requires
> connected operation, UDP *can* operate connected, but does not
> *require* it.
>
>
>> What I think is a Lisp stream, which I can read-
>> byte from it.
>
> While I'm not strongly opposed to it, I think of UDP packets as
> messages: self-containing units of information (in this case: serios
> octets) with no strong relation to previous or following messages.
> Looking at it this way makes the stream variant a bit awkward. Having
> SOCKET-RECEIVE return an array of octets however looks to me like it
> matches the "messages" pattern better. But, as I said, I'm not opposed
> to also providing a stream interface on those implementations which
> support it.
>
>> Some network protocol's design goal is to make sure
>> application can start decoding message even before all data transfer
>> is done. SNMP is just in this class. In my implementation, I read  
>> byte
>> one by one to decode it, the length of one snmp message can be found
>> in almost first two bytes so I can decide how many bytes should I
>> read. If just use SOCKET-RECEIVE, it will be inconvenient...
>
> Ok. What's the difference between reading 2 octets from a stream or
> being returned 2 octets from READ, btw? :-)

Ah, yes, actually no difference, I can always build a fake stream from  
these return bytes for my personal use.
So I completely agree with you now:)

OK, so if I can see some interface function (like SOCKET-RECEIVE) in  
svn trunk, I'll start to learn them and write/test some backend code  
as your design and commit to you, and I'll start to make my package  
depends on usocket to get networking portability.

Regards,

Chun TIAN (binghe)


>
>
>
> bye,
>
>
> Erik.