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

[Chris Hall]

<address@hidden> writes:

> What is returned by ACCEPT-SOCKET-CONNECTION cannot be read or written
> (as is possible with a socket resulting from SOCKET).  This is what I
> observe on GCL 2.6.1 on Red Hat 8.0 (kernel 2.4.18-14).
>
> Maybe I'm confused, but I thought what comes back from an
> ACCEPT-SOCKET-CONNECTION should be the same thing that comes back from
> SOCKET.
>

That was my initial thought too, so I was surprised when they returned
different values - ones gets a two stream:

gcl>(si::socket 5500 :host "localhost")
#<two-way stream 08830e7c>

gcl>(si::accept-socket-connection (si::open-named-socket 5600))
(("address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden
address@hidden@address@hidden@address@hidden@address@hidden"  . "127.0.0.1") 3 
. 5600)

(Munged for Usenet)

The odd looking string is a string representaion of a C structure used
by GCL internally, and contains things like packets sent, packets
received, etc.

Grepping through the GCL source, ACCEPT-SOCKET-CONNECTION occurs exactly
once, used in gcl-tk/tkl.lisp:

  (setq *tk-connection* (si::accept-socket-connection tk-socket ))

It would seem that the original support for sockets was for the Tk GUI
stuff, and some kind soul later added SI:SOCKET.

Camm has mentioned that other than SI::SOCKET, the socket functions at
the C-level are using something called 'magic numbers' in the packet
headers, if that means anything to you - it only vaguely does to me.

> Given what you say below, it sounds like you know what you're doing.
> What I can't figure out (so far) is how the implementors meant to be using
> file descriptors, streams and sockets in the current C implementation.

Heh!  If only!

> I've *used* sockets and server sockets in C and in Java but
> don't particularly want to implement the low level mechanics for GCL.
> After looking at what it returned by ACCEPT-SOCKET-CONNECTION, it
> seems as if the original implementer had something in mind that I'm

As above, support for connecting to and conversing with a Tk server, in
order to do GUI apps from GCL.  At least that what it looks like to me.

> just not following.  Mainly I believe that I'd just make things worse
> if I tried to change the C code.
>
> Tom Johnson
>

I'm thinking/hoping it may more be a case of copying and adding a bit -
the code is already there to a create a two-way character stream by
connecting to something _from_ GCL - all we need now is something to
return the same thing after something connects _to_ GCL.

*Sounds* pretty straightforward, anyway. ;-D

Aloha,
+Chris

-- 
You can't build a reputation on what you are going to do.
-- Henry Ford (1863 - 1947)

pgpFlWY8EIXTs.pgp
Description: PGP signature