Interest in sockets package development

Interest in sockets package development

[Chad R. Meiners]

I am currently developing a LGPL'ed thick binding for sockets in my spare
time.  The purpose of this binding is to provide better control of sockets
in a multi-tasking environment.  For example the binding will manually block
the procedure calls on protected object thus allowing tasks blocks on reads
to be aborted if necessary (this is opposed to allowing the OS to block each
task).  Another feature I plan on including is an event queue type that will
allow programs to manage a large number of sockets.  Does anyone have any
interests in using such a binding.  My first release will be for Win32
platforms, but I am planning on developing a Unix port after I am done with
the Win32 version.

-CRM

Re: Interest in sockets package development

[David Botton]

> I am currently developing a LGPL'ed thick binding for sockets in my spare
> time.  The purpose of this binding is to provide better control of sockets
> in a multi-tasking environment.

Is It not possible to use GNAT.Sockets to do this already?

David Botton

Re: Interest in sockets package development

[Florian Weimer]

"David Botton" <David@Botton.com> writes:

>> I am currently developing a LGPL'ed thick binding for sockets in my spare
>> time.  The purpose of this binding is to provide better control of sockets
>> in a multi-tasking environment.
>
> Is It not possible to use GNAT.Sockets to do this already?

Has ACT made a public release yet?

Re: Interest in sockets package development

[Marin David Condic]

Maybe an acceptable solution, but it doesn't leave your code
compiler-independent. Something that may be an issue for some apps.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"David Botton" <David@Botton.com> wrote in message
news:mailman.1000010949.32495.comp.lang.ada@ada.eu.org...
> > I am currently developing a LGPL'ed thick binding for sockets in my
spare
> > time.  The purpose of this binding is to provide better control of
sockets
> > in a multi-tasking environment.
>
> Is It not possible to use GNAT.Sockets to do this already?
>

Re: Interest in sockets package development

[David C. Hoos, Sr.]

David,

Am I mistaken, or is GNAT.Sockets available publicly somewhere
of which I am not aware?

----- Original Message ----- 
From: "David Botton" <David@Botton.com>
To: <comp.lang.ada@ada.eu.org>
Sent: September 08, 2001 11:48 PM
Subject: Re: Interest in sockets package development


> I am currently developing a LGPL'ed thick binding for sockets in my spare
> time.  The purpose of this binding is to provide better control of sockets
> in a multi-tasking environment.

Is It not possible to use GNAT.Sockets to do this already?

David Botton

_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: Interest in sockets package development

[David Botton]

I may have overlooked that it was part of GNAT Pro and not in the latest
public release, but I don't have the public release installed right now to
check.

Either way, since ACT has up to now maintained a policy of publicly
releasing their compiler (which includes a lot of great packages in the GNAT
heiharachy) it is still worth mentioning to avoid duplicating efforts.

Also, AdaSockets is a publicy available package that perhaps may also
provide the functionality Chad Meiners was looking for.


David Botton


----- Original Message -----
From: "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com>


> David,
>
> Am I mistaken, or is GNAT.Sockets available publicly somewhere
> of which I am not aware?

Re: Interest in sockets package development

[Simon Wright]

"David Botton" <David@Botton.com> writes:

> I may have overlooked that it was part of GNAT Pro and not in the
> latest public release, but I don't have the public release installed
> right now to check.

It is only in GNATpro (so far).

Re: Interest in sockets package development

[tmoran]

> Also, AdaSockets is a publicy available package that perhaps may also
> provide the functionality Chad Meiners was looking for.
  Also Claw.Sockets (www.rrsoftware.com).

Re: Interest in sockets package development

[Chad R. Meiners]

I have used AdaSockets for previous projects before, but it doesn't scale up
well since you have to allocate a task per socket due to the sockets
blocking.  I don't mind dealing with blocking sockets in fact I prefer them
to non-blocking sockets.  Thus what I really want so is a nice queue I can
tell my set of sockets to drop an event into the queue so I can block a
couple worker tasks on the queue instead of having a task per socket.  So
far I haven't seen any LGPL'd package that does this; therefore, I have
taken it upon myself to create such a package.  I remember a while back
someone was complaining about how the available packages for sockets didn't
scale up well for a large number of sockets.  It had something to do with
the select function being difficult.  At that point I decided that I was
going to someday (if I had the time) solve this problem even if it meant I
had to redesign the socket interface.  So over the months whenever I got
bored I browsed through the Winsock api's looking for a better way to
implement a sockets package.   I figured out a nice solution a while back
but until now I haven't had the time to implement it.  The original point of
my post was to ask if anyone out there was interested in this development.

I remember a while back someone pointed to the original sockets package that
GNAT.Sockets came from; I checked it out and decided that it did not satisfy
my requirements.  I do not know if this is still true, but since I am a grad
student I doubt that I will see Gnat(Pro) anytime soon ;)  If someone would
like to send me the spec files for GNAT.Sockets it might save me a good deal
of work if it turns I that I would be duplicating effort without adding
anything new and exciting *grin*

So let us return to the original subject ...  Does anyone here have any
interest in a sockets package that handles a large number of sockets
elegantly?

-Chad R. Meiners

Re: Interest in sockets package development

[tmoran]

>I have used AdaSockets for previous projects before, but it doesn't scale up
>well since you have to allocate a task per socket due to the sockets
>...
>interest in a sockets package that handles a large number of sockets
>elegantly?
  What do you mean by "a large number"?

>of work if it turns I that I would be duplicating effort without adding
>anything new and exciting *grin*
  I've e-mailed the public spec of Claw.Sockets.Non_Blocking (which
is not included in the intro version of Claw).  Perhaps it will be
helpful.

Re: Interest in sockets package development

[Tony Gair]

Hi Chad


On Sun, 9 Sep 2001 21:14:42 -0400
"Chad R. Meiners" <crmeiners@hotmail.com> wrote:

> I have used AdaSockets for previous projects before, but it doesn't scale up
> well since you have to allocate a task per socket due to the sockets
> blocking.  I don't mind dealing with blocking sockets in fact I prefer them
> to non-blocking sockets.  Thus what I really want so is a nice queue I can
> tell my set of sockets to drop an event into the queue so I can block a
> couple worker tasks on the queue instead of having a task per socket.  So
> far I haven't seen any LGPL'd package that does this; therefore, I have
> taken it upon myself to create such a package.  I remember a while back
> someone was complaining about how the available packages for sockets didn't
> scale up well for a large number of sockets.  It had something to do with
> the select function being difficult.  At that point I decided that I was
> going to someday (if I had the time) solve this problem even if it meant I
> had to redesign the socket interface.  So over the months whenever I got
> bored I browsed through the Winsock api's looking for a better way to
> implement a sockets package.   I figured out a nice solution a while back
> but until now I haven't had the time to implement it.  The original point of
> my post was to ask if anyone out there was interested in this development.
> 
> I remember a while back someone pointed to the original sockets package that
> GNAT.Sockets came from; I checked it out and decided that it did not satisfy
> my requirements.  I do not know if this is still true, but since I am a grad
> student I doubt that I will see Gnat(Pro) anytime soon ;)  If someone would
> like to send me the spec files for GNAT.Sockets it might save me a good deal
> of work if it turns I that I would be duplicating effort without adding
> anything new and exciting *grin*
> 
> So let us return to the original subject ...  Does anyone here have any
> interest in a sockets package that handles a large number of sockets
> elegantly?
> 
> -Chad R. Meiners
> 
> 

Re: Interest in sockets package development

[Tony Gair]

Hi Chad, 
	I am in the process of making two libraries to represent two socket servers
one listens to a socket, starts a connection (and a new task to keep listening for new
connections). The sockets can pass any variant record type. My intention is for both
the server and the client to react on the receipt of these records.

Whilst it is fairly basic it does fit with tasking quite well and can be used to drive
to drive a user interface and drive events on the server side on an internet application
used in conjunction with GTKada...

Only problem, I am still debugging it and have been going for three weeks, S. Tardieu wrote 
his socket package in a half day. You're welcome for a look
Tony Gair 


On Sun, 9 Sep 2001 21:14:42 -0400
"Chad R. Meiners" <crmeiners@hotmail.com> wrote:

> I have used AdaSockets for previous projects before, but it doesn't scale up
> well since you have to allocate a task per socket due to the sockets
> blocking.  I don't mind dealing with blocking sockets in fact I prefer them
> to non-blocking sockets.  Thus what I really want so is a nice queue I can
> tell my set of sockets to drop an event into the queue so I can block a
> couple worker tasks on the queue instead of having a task per socket.  So
> far I haven't seen any LGPL'd package that does this; therefore, I have
> taken it upon myself to create such a package.  I remember a while back
> someone was complaining about how the available packages for sockets didn't
> scale up well for a large number of sockets.  It had something to do with
> the select function being difficult.  At that point I decided that I was
> going to someday (if I had the time) solve this problem even if it meant I
> had to redesign the socket interface.  So over the months whenever I got
> bored I browsed through the Winsock api's looking for a better way to
> implement a sockets package.   I figured out a nice solution a while back
> but until now I haven't had the time to implement it.  The original point of
> my post was to ask if anyone out there was interested in this development.
> 
> I remember a while back someone pointed to the original sockets package that
> GNAT.Sockets came from; I checked it out and decided that it did not satisfy
> my requirements.  I do not know if this is still true, but since I am a grad
> student I doubt that I will see Gnat(Pro) anytime soon ;)  If someone would
> like to send me the spec files for GNAT.Sockets it might save me a good deal
> of work if it turns I that I would be duplicating effort without adding
> anything new and exciting *grin*
> 
> So let us return to the original subject ...  Does anyone here have any
> interest in a sockets package that handles a large number of sockets
> elegantly?
> 
> -Chad R. Meiners
> 
> 

Re: Interest in sockets package development

[Ted Dennison]

In article <9neodq$1vcs$1@msunews.cl.msu.edu>, Chad R. Meiners says...
>
>I am currently developing a LGPL'ed thick binding for sockets in my spare
>time.  The purpose of this binding is to provide better control of sockets

Bindings should *not* use the LGPL. That license was designed for link
libraries, not compiled-in source code. In some ways it is actually *more*
restrictive than the GPL in this environment.

Most Free binding authors these days use the GPL with exemptions for "with"ing
source, as the Gnat runtime does. This is commonly known as the Gnat-Modified
GPL, or GMGPL. To do this, you just add the standard GPL notice to your source
file headers, but follow it up with this:

-- As a special exception, if other files instantiate generics from this
-- unit, or you link  this unit with other files to produce an executable,
-- this unit does not by itself cause the resulting executable to be
-- covered by the GNU General Public License. This exception does not
-- however invalidate  any other reasons why the executable file might be
-- covered by the GNU Public License.                                     
--      

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Interest in sockets package development

[Matthew Woodcraft]

Ted Dennison<dennison@telepath.com> writes:

> Bindings should *not* use the LGPL. That license was designed for link
> libraries, not compiled-in source code. In some ways it is actually *more*
> restrictive than the GPL in this environment.

The LGPL explicitly allows you to treat LGPL-licensed software as
GPLed instead (as a one-time conversion), so it can never really be
more restrictive than the GPL.

-M-

Re: Interest in sockets package development

[Chad R. Meiners]

You're right.  I have been thinking the LGPL <=> Gnat-Modified GPL.  I
intended to Gnat-Modified GPL.  Thank you for pointing that out. ;)

-CRM

"Ted Dennison" <dennison@telepath.com> wrote in message
news:nX3n7.2191$%u4.2297@www.newsranger.com...
> In article <9neodq$1vcs$1@msunews.cl.msu.edu>, Chad R. Meiners says...
> >
> >I am currently developing a LGPL'ed thick binding for sockets in my spare
> >time.  The purpose of this binding is to provide better control of
sockets
>
> Bindings should *not* use the LGPL. That license was designed for link
> libraries, not compiled-in source code. In some ways it is actually *more*
> restrictive than the GPL in this environment.
>
> Most Free binding authors these days use the GPL with exemptions for
"with"ing
> source, as the Gnat runtime does. This is commonly known as the
Gnat-Modified
> GPL, or GMGPL. To do this, you just add the standard GPL notice to your
source
> file headers, but follow it up with this:
>
> -- As a special exception, if other files instantiate generics from this
> -- unit, or you link  this unit with other files to produce an executable,
> -- this unit does not by itself cause the resulting executable to be
> -- covered by the GNU General Public License. This exception does not
> -- however invalidate  any other reasons why the executable file might be
> -- covered by the GNU Public License.
> --
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com