[usocket-devel] LispWorks and UDP

[Chun Tian (binghe)]

On Feb 1, 2008, at 7:38 AM, Erik Huelsmann wrote:

> On Jan 31, 2008 11:54 PM, Chun Tian (binghe) <binghe.lisp at 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 at 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
>>>
>>> 1) 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).

(I'm living in timezone +0800, China)

Good, I'm reading your exist code. If you can make a UDP interface  
specification, then I think I can do some of the under implementation  
part.

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


Oh, I know now. We can use a interface to get a socket, whatever it's  
IP-based, then use another independent interface to send/receive data  
gram, am I right?

That seem more difficult work on the interface definition, things on  
this level may only be done by yourself, my network knowledge is very  
limited, sorry. Instead I can do some easy part, for example,  
implement your spec in some CL.


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