On Jan 31, 2008 11:54 PM, Chun Tian (binghe) binghe.lisp@gmail.com wrote:
On Feb 1, 2008, at 5:27 AM, Erik Huelsmann wrote:
On Jan 30, 2008 4:03 AM, Chun Tian (binghe) binghe.lisp@gmail.com wrote:
Hi, Erik
I'm a Linux system administrator, and I need a UDP universal interface for my SNMP, and IPMI work. Now I have to port to every CL platform by myself, but I think maybe I should do this by patch usocket to support UDP.
Ah. In that case, sorry for misunderstanding you. I thought that you were offering me to be allowed to integrate your UDP code into the usocket code base. Now I think I understand that you want to work with me on getting UDP implemented on at least 3 backends.
Ofcourse, working together on integrating UDP for more than one backend is absolutely fine. I've looked at your udp lispworks link.
Thanks.
While studying sockets and especially datagram sockets, I found that there are 2 ways for a datagram socket to operate
- connected - in which case it operates like a tcp socket, sending
packets to and receiving from one peer (except for the streamy properties) 2) unconnected - in which case the socket can send messages to and receive messages (datagrams) from any other IP address
When implementing UDP, I think it would be wise to decide beforehand if it will be possible to implement both modes of operation and if so, how. I see you only implemented (1); did you not care about (2), or have you already decided it won't be possible to implement it?
Unconnected UDP networking, something like the socket function "sendto" and "recvfrom"?
Yes, recvfrom and sendto. Actually, if there implementations which don't support recv() and send() but do support recvfrom() and sendto(), all we need is the last two: recv and send can be implemented using the other 2.
Yes, I'll need them. In SNMP protocol, I've only implemented the GET and GET-NEXT pdu right now, they are session based, so I choose a connected UDP interface. the TRAP pdu, which only send a UDP packet to remote server (a snmptrapd) and not get any response, I think it's better implemented under a unconnected UDP. I already plan to do this in next days.
That's great news! Ofcourse, there's no need to implement all three backends right now. The main point is that we do this together (sharing the burden), instead of me having to do all the work. If you don't mind, I'll set out to write my ideas about the implementation of UDP within usocket tomorrow night (it's past midnight here in Europe now).
On the other hand, I don't think it's impossible for any Common Lisp platform which support FFI interface but cannot call a socket UDP function. We can reuse their already exported UDP functions, and when they haven't, we just export them by ourself, like those you already did in usocket source code.
But please don't write any C code, just FFI is enough,
Yes: that's one of the design goals of usocket (to integrate as tightly as possible with the different implementations). I've used the available ffi implementations of each lisp (this means that I *did* get to write C code to support ECL, but that's just ECLs way of providing FFI). The fact that I used each lisps FFI and not UFFI is a conscious choice. I'd like to go deeper down that road.
this will bring difficulty in porting to some platform, like win32.
Well, all platforms usocket currently supports (including win32) have a BSD style socket interface, so even porting sockets to Windows should not be a huge task, but if it's not necessary, even the better.
A project, iolib, which use FFI and C code to build a POSIX environment for Common Lisp and do have a universal socket interface. I used to depend it, but soon find this package is very hard to support win32, and I gived up, turn to packages with pure lisp, like usocket.
Thanks (I take that as a complement!).
As far as usocket goes: yes, I have a bit of framework already set up, but it's only minor: there is a datagram-usocket class reserved for exactly this purpose. What I've done however is decide to (try to) keep usocket interfaces from being explicitly IP specific. This means that UDP would be implemented in terms of a datagram protocol, without hardcoding specifics of IP address/port combinations. (Unfortunately, socket-connect isn't a good example of this.) When we can stick to that goal, it would be great for me.
If I didn't misunderstand, a "connected UDP socket" will be IP address/ port specific, so you mean, we only do the (2), not (1) ?
Well, what I meant is: UDP is an IP based datagram protocol. However BSD sockets also support datagrams over ATM or other (non-IP) protocols. The IP-address/portnumber pair is an IP specific detail. ATM may use other adressing methods.
Maybe the above paragraph is too abstract and we may need to run into what I mean. At that time, I'll try to explain what I mean and we'll get past it then. No problem.
bye,
Erik.
Is there any UDP porting framework which already exist in usocket? I'm very interesting in getting UDP support to work on LispWorks, SBCL, and OpenMCL, the three main platforms I use.
No problem. If you can do those 3, I'll try to find time to do any others we find necessary before we can declare a new release.
So, do you agree with the above? Can we work on this together?
bye,
Erik.
Regards,
Chun TIAN (binghe)
On Jan 29, 2008 8:21 PM, Chun Tian (binghe) binghe.lisp@gmail.com wrote:
Hi, usocket developer
Recently I wrote a LispWorks UDP support package for my pure lisp SNMP package. I use the FFI function which already in LispWorks to do a UDP job, and implement a interface which very like the exist TCP interface.
You can find my code here:
URL: https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/lispworks-udp/tr...
Seems LispWorks, Ltd. didn't have any plan for UDP support, this package may help for usocket to implement a universal socket interface. I'll be glad for usocket to use my code, you can asdf depend it or just merge it.
Thanks for the offer! I'm still working at 'tidying up' the TCP support, but once that's done, I'll be sure to have a look at your UDP code, because we'll want to offer UDP to usocket users when TCP is available.
Thanks again!
bye,
Erik.