Re: [Gcl-devel] Re: Server sockets with GCL?

[Camm Maguire]

Greetings!

A few observations regarding sockets in GCL:

1) There appears to be hooks in the current code for functions which
   were later removed, perhaps as a result of the KCL->GCL migration.
   Look at nsocket.c for the commented out empty function update,
   etc.   

2) From what I can tell, the server function passed to si::socket is
   therefore not currently used.  I've checked all the references to
   object0->c.c... and unless I've missed something, this
   functionality has been removed.

3) The code in file.d goes with the routines in nsocket.c.  The code
   in sockets.c appears to be tcltk specific, going with
   gcl-tk/comm.c.  The magic header bytes are indeed gcl specific
   additions to the protocol to the gcltkserver, presumably as a
   failsafe.  Search for 'magic' in gcl-tk/comm.c.

4) Fixing this is not hard -- its just that it is not clear what is
   best to do.  As we all know, there is no socket standard in the
   ANSI spec.  It has been expressed that compatibility with allegro
   would be desirable, at least for SLIME, but there appears to be no
   multiplexing ability in their implementation.  Presumably this is
   because they count on the user relying on threads for their
   multitasking.  The dominant socket server paradigm of which I am
   aware is 1) bind 2) listen 3) accept 4) fork/spawn, whatever on the
   new socket.  This would be simple to implement in GCL via fork()
   (no Windows), but this would mean running one image per connection,
   which is quite a lot of memory.  Threads reduce this hurdle, but
   they are much harder in lisp, where one has to worry about the GC.
   We won't be able to do that any time soon, at least without some
   detailed pointers/examples of other treatments.  So this might
   indicate that either 1) a multiplexing based on select() or 2) a
   SIGIO based multitasking system might be preferable.  I've had a
   bit of trouble with SIGIO signal handlers restarting some system
   calls on exit in the past -- don't know if this is a permanent
   problem.  

   Presumably one does want to assign some function to handle the i/o
   on the socket *in the background* while returning control to the
   user, no?  Would it not also be preferable to have some sort of
   attach/detach procedure like in gdb to connect and disconnect from
   a running process?

   BTW, noticed on allegro's site that SSL is only supported in
   Enterprise versions.  I've written my own ssl socket multiplexer
   (non-server) in C, which in principle is easily integratable into
   GCL if an interface can be decided upon, using openssl, so maybe
   this would be attractive.

5) Speaking of fork(), I just noticed that we are not even compiling
   in run-process and the like, at least on linux.  Does anyone want
   this back?

Take care,


Jeff Dalton <address@hidden> writes:

> Quoting Chris Hall <address@hidden>:
> 
> > > What I'm confused about is how to take the results obtained from
> > > calling ACCEPT-SOCKET-CONNECTION and derive a pair of streams.
> > 
> > I'd like to do this, too, but after looking at the existing C socket
> > code that I can find in GCL and reading what Camm has to say, it seems
> > it some work needs to be done on the C side.  I am, when I can spend
> > the time, learning what I can about C socket programming on Linux.
> 
> When I did socket stuff in GCL in order to write an HTTP server,
> I wrote a function called accept-socket-connection that returned
> an df (ie, an int), and I wrote something called fdopen that
> would return a Lisp input or output stream.  Then
> 
> (defun socket-connection-stream (s)
>   (let ((fd (accept-socket-connection s)))
>     (make-two-way-stream
>       (fdopen fd :input)
>       (fdopen fd :output))))
> 
> fdopen was named after the C procedure that makes a FILE from an fd.
> 
> I could then do normal I/O with the resulting stream.
> 
> All of this was reasonably straightforward to do using the C
> interface.
> 
> I'm not sure how freely available my code is, though it's supposed
> to become open source as part of O-Plan (an AI planning system)
> at some point.
> 
> However, I'd be ahppy to try to help other people with such
> things where I can.
> 
> BTW, is there any documentation for the GCL C interface.
> My copy of the KCL manual was destroyed in a fire, and I
> couldn't find anything on-line.
> 
> -- Jeff
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah