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

[Erik Huelsmann]

> >
> > 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? :-)


bye,


Erik.