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

Chun Tian (binghe) binghe.lisp at gmail.com
Sat Feb 2 10:12:58 UTC 2008


Hi again

On Feb 2, 2008, at 7:03 AM, Erik Huelsmann wrote:

> When looking at usocket.lisp, you'll find there is a datagram-usocket
> class commented out. I think this class (even without any additional
> slot definitions) should be used for UDP sockets.
>
> Then there's datagram-usocket-p, which should start returning T when
> the passed in object is a true descendant of DATAGRAM-USOCKET.

no question this part.

>
>
> 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 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.

>
>
>
> 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. What I think is a Lisp stream, which I can read- 
byte from 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...

>
>
> Oh. One last thing: local and peer address retrieval functions should
> be adapted to apply to UDP sockets as well as the currently supported
> stream sockets.

no question this part.

>
>
> I hope this is all a bit clear! If you have (m)any questions, please
> don't hesitate to ask.
>
> Bye,
>
>
> Erik.




More information about the usocket-devel mailing list