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.