Datagram/UDP support

Hi,

I know this question has been asked before, but it remains unanswered:  
I think it really silly that such a professional CL implementation and  
environment like LispWorks doesn't include support for Datagram/UDP  
out of the box, across all platforms. Java has it, Allegro CL has it,  
it is even pretty simple in C. The needed API to be added to COMM can  
be very small:

Using a datagram-socket class,

	(make-instance 'datagram-socket)

for a client-style socket, or

	(make-instance 'datagram-socket :port 12345)

for a server-style socket, additional keywords like
:read-timeout could added as well

The 2 essential function could be:

	(send-datagram datagram-socket host port bytes)

to send a datagram, returning nothing, and possibly
signalling some conditions and

	(receive-datagram datagram-socket)
	=> bytes, host, port

to receive a datagram, returning 3 values, the bytes,
a host and a port, blocking during read-timeout, or

	(receive-datagram datagram-socket buffer)
	=> bytes-read, host, port

with the option to pass a predefined buffer to
be filled, like in read-sequence, returning the 3
values bytes-received, host, port, possibly some
condition could be signalled here too and finally,

	(close datagram-socket)

How long could this take LispWorks' developers to implement ?
Does this really require 'Chargeable Support Incidents' ?
How many ?
Anybody else wants this too ?

Sven

Re: Datagram/UDP support

On Fri, 16 May 2008 12:58:24 +0200, Sven Van Caekenberghe <sven@beta9.be> wrote:

> How long could this take LispWorks' developers to implement ?  Does
> this really require 'Chargeable Support Incidents' ?  How many ?

This looks like something you should send to LW Support and not to the
mailing list.

> Anybody else wants this too ?

I don't have a pressing need for it.  I remember I used it once years
ago (in Perl) and at that time I was happy to have it available.  So,
I certainly wouldn't mind if it were suddenly there in the next
release... :)

Edi.

Re: Datagram/UDP support

You're probably not going to like this answer, but if I needed this I'd simply write a small library in C if I didn't want to use a support incident.

At the risk of speaking out of turn, I think LispWorks is a small company with a *lot* of work to do, and like any small outfit they must prioritize work. Yeah, to us on the outside UDP support seems such a small thing; but to the developers in the trenches with feature lists a mile long UDP is competing with a thousand other things for attention.

Write the library in C, and do the FFI hooks. It'll be fun. You'll see.

-- david

On Fri, May 16, 2008 at 6:58 AM, Sven Van Caekenberghe <sven@beta9.be> wrote:

Hi,

I know this question has been asked before, but it remains unanswered: I think it really silly that such a professional CL implementation and environment like LispWorks doesn't include support for Datagram/UDP out of the box

--
And now these three remain: faith, hope, and love.
But the greatest of these is love.
-- 1 Corinthians 13:13

For wisdom is more precious than rubies,
and nothing you desire can compare with her.
-- Proverbs 8:11

Re: Datagram/UDP support

2008/5/16 David Young <youngde811@gmail.com>:

> Write the library in C, and do the FFI hooks. It'll be fun. You'll see.

It would still be nice to have it out of the box :-)


-- 

 (Rmz)

Re: Datagram/UDP support

Absolutely. Perhaps one day.

-- david

On Fri, May 16, 2008 at 9:37 AM, Bjørn Remseth <la3lma@gmail.com> wrote:

2008/5/16 David Young <youngde811@gmail.com>:

> Write the library in C, and do the FFI hooks. It'll be fun. You'll see.

It would still be nice to have it out of the box :-)

--

(Rmz)

Re: Datagram/UDP support

"David Young" <youngde811@gmail.com> writes:

> You're probably not going to like this answer, but if I needed this I'd
> simply write a small library in C if I didn't want to use a support
> incident.

Or just download it:
<http://article.gmane.org/gmane.lisp.lispworks.general/2278>

-- 
Mvh/Regards
Peder O. Klingenberg
Netfonds Bank ASA

Re: Datagram/UDP support

Even better!

dey

On Fri, May 16, 2008 at 10:20 AM, Peder O. Klingenberg <pok@netfonds.no> wrote:

Or just download it:
<http://article.gmane.org/gmane.lisp.lispworks.general/2278>

--
Mvh/Regards
Peder O. Klingenberg
Netfonds Bank ASA

Re: Datagram/UDP support

And try this: (use Subversion to get it)

LispWorks-UDP, UDP Server/Client support for LispWorks:

$ svn co https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/lispworks-udp/trunk

I wrote it for SNMP which based on UDP, it's pure lisp and FLI-based.  
It's almost stable. See test.lisp for sample use.

P.S. There's at least one customer whom used my LispWorks-UDP package  
for porting UDP-based project from MCL to LW.

Regards,
Chun Tian (binghe)

> Hi,
>
> I know this question has been asked before, but it remains  
> unanswered: I think it really silly that such a professional CL  
> implementation and environment like LispWorks doesn't include  
> support for Datagram/UDP out of the box, across all platforms. Java  
> has it, Allegro CL has it, it is even pretty simple in C. The needed  
> API to be added to COMM can be very small:
>
> Using a datagram-socket class,
>
> 	(make-instance 'datagram-socket)
>
> for a client-style socket, or
>
> 	(make-instance 'datagram-socket :port 12345)
>
> for a server-style socket, additional keywords like
> :read-timeout could added as well
>
> The 2 essential function could be:
>
> 	(send-datagram datagram-socket host port bytes)
>
> to send a datagram, returning nothing, and possibly
> signalling some conditions and
>
> 	(receive-datagram datagram-socket)
> 	=> bytes, host, port
>
> to receive a datagram, returning 3 values, the bytes,
> a host and a port, blocking during read-timeout, or
>
> 	(receive-datagram datagram-socket buffer)
> 	=> bytes-read, host, port
>
> with the option to pass a predefined buffer to
> be filled, like in read-sequence, returning the 3
> values bytes-received, host, port, possibly some
> condition could be signalled here too and finally,
>
> 	(close datagram-socket)
>
> How long could this take LispWorks' developers to implement ?
> Does this really require 'Chargeable Support Incidents' ?
> How many ?
> Anybody else wants this too ?
>
> Sven
>
>