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.
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 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 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.
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.
I hope this is all a bit clear! If you have (m)any questions, please don't hesitate to ask.
Bye,
Erik.
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.
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.
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.
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.
I'm sorry you didn't see anything yet. The commits you've seen until today were about me cleaning up loose ends and implementing ideas floating in my head for months (as I could not commit them - my hd had crashed). I need to get rid of that mental state to be able to start the UDP work, so, that's why. I hope to be able to do some interface definition work today.
If you have any questions, or need some information to be able to proceed, don't hesitate to say so!
bye,
Erik.
On Feb 16, 2008 8:51 PM, Erik Huelsmann ehuels@gmail.com wrote:
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.
I'm sorry you didn't see anything yet. The commits you've seen until today were about me cleaning up loose ends and implementing ideas floating in my head for months (as I could not commit them - my hd had crashed). I need to get rid of that mental state to be able to start the UDP work, so, that's why. I hope to be able to do some interface definition work today.
I was going to work with CLISP to do some exploration on this front, but it turns out that the default Etch CLISP package doesn't include the RAWSOCK module which I'll need to implement this feature... So, instead of designing/working on a prototype, I ended up trying to compile my own CLISP.
Hopefully more later.
bye,
Erik.
On Feb 16, 2008 8:51 PM, Erik Huelsmann ehuels@gmail.com wrote:
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.
I'm sorry you didn't see anything yet. The commits you've seen until today were about me cleaning up loose ends and implementing ideas floating in my head for months (as I could not commit them - my hd had crashed). I need to get rid of that mental state to be able to start the UDP work, so, that's why. I hope to be able to do some interface definition work today.
I was going to work with CLISP to do some exploration on this front, but it turns out that the default Etch CLISP package doesn't include the RAWSOCK module which I'll need to implement this feature... So, instead of designing/working on a prototype, I ended up trying to compile my own CLISP.
Hi, Erik
Debian's CLISP package is a bit strange, which didn't compile many module which CLISP supported. Maybe you should submit this to Debian as a wishlist.
The past two weeks is Spring Festival - a very big holiday for all Chinese, and I didn't do anything on Lisp. My current plan is more developments on my SNMP package, and start a new project: IPMI[1] for Lisp (which still depends on a UDP support for at least LispWorks). I'll continue watching usocket's change and do my job as we talk before.
Regards,
Chun TIAN (binghe)
[1] http://www.intel.com/design/servers/ipmi/
Hopefully more later.
bye,
Erik.
On 2/18/08, Chun Tian (binghe) binghe.lisp@gmail.com wrote:
On Feb 16, 2008 8:51 PM, Erik Huelsmann ehuels@gmail.com wrote:
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.
I'm sorry you didn't see anything yet. The commits you've seen until today were about me cleaning up loose ends and implementing ideas floating in my head for months (as I could not commit them - my hd had crashed). I need to get rid of that mental state to be able to start the UDP work, so, that's why. I hope to be able to do some interface definition work today.
I was going to work with CLISP to do some exploration on this front, but it turns out that the default Etch CLISP package doesn't include the RAWSOCK module which I'll need to implement this feature... So, instead of designing/working on a prototype, I ended up trying to compile my own CLISP.
Debian's CLISP package is a bit strange, which didn't compile many module which CLISP supported. Maybe you should submit this to Debian as a wishlist.
I found that this wasn't really a problem in my CLISP at all. After I found out that the (CLISP provided) Win32 package had the same problem, I discovered the -Kfull option I should have provided at startup. After doing so, CLISP turned out to support RAWSOCK afterall!
The past two weeks is Spring Festival - a very big holiday for all Chinese, and I didn't do anything on Lisp. My current plan is more developments on my SNMP package, and start a new project: IPMI[1] for Lisp (which still depends on a UDP support for at least LispWorks). I'll continue watching usocket's change and do my job as we talk before.
Great! I don't really know yet how to handle UDP socket creation, but I'll continue defining other functions with fewer "problems" asap.
Bye,
Erik.
Hi, Erik
I attached a patch, which implemented SOCKET-SEND and SOCKET-RECEIVE for LispWorks. I use recvfrom() and sendto() to do this.
But what I don't know is the API of UDP socket creation: I must make a socket fd first, then send/reveive messages. Could you give me some advice?
Regards, Chun Tian (binghe)
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.
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 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 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.
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.
I hope this is all a bit clear! If you have (m)any questions, please don't hesitate to ask.
Bye,
Erik.
Additional USOCKET API changes beside SOCKET-RECEIVE and SOCKET-SEND:
1. Add a new keyword argument to SOCKET-CONNECT: (PROTOCOL :TCP). When giving (:PROTOCOL :UDP) to SOCKET-CONNECT, this function should return a DATAGRAM-USOCKET
There're two cases when PROTOCOL is :UDP
* (and HOST PORT), do a connect() as additional to socket(), * (not (and HOST PORT), only call socket().
2. Add a new function: SOCKET-SYNC as high-level UDP message send/recv function, which can support packet retransmit and auto-learnt timeout value.
3. Add a new function: SOCKET-SERVER to create a simple UDP server.
I think above changes will not effect exist applications which don't know UDP.
--binghe
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.
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 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 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.
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.
I hope this is all a bit clear! If you have (m)any questions, please don't hesitate to ask.
Bye,
Erik.
-
Chun Tian (binghe) -
Erik Huelsmann