[GRASS5] sockets question

[Eric G. Miller]

On Wed, Mar 14, 2001 at 03:55:30AM -0800, strobe anarkhos wrote:
> I'm moving forward on my plan to improve GRASS 2D display (adding
> layers, alpha channel, resolution independent graphics, rulers,
> WYSIWYG printing, etc.) . I have a small question about sockets.
> 
> I'm using GRASS 5 as my base and thus am using fifos in a fully
> compatible fashion to other grass5 display drivers. To my knowledge
> the developmental version 5.1 is using sockets instead of fifos to
> connect the display commands to the servers.
> 
> Are clients pushing the same data to the servers in 5.1?

What you'll want to look at is the src/libes/raster code, and then
mostly the SWITCHER.c.  If you look at the SWITCHER.c in
src/display/devices/XDRIVER/XDRIVER24/socket.new/  you'll see how I'm
currently handling (a) getting the socket file path, (b) checking if the
socket is in use, (c) binding to the socket (returns a file descriptor),
(d) fork, then start listening on the "bound" file descriptor, (e) then
using select() with the listening file descriptor; on "timeout", process
Xevents; on connection pending, accept the connection and see what the
client wants (i.e. process requests).

The modules don't know anything about the communications path; that's
handled by the misnamed "raster" library function calls.  The various
wrapper routines "G_sock_*" are in src/gis/libes/unix_socks.c.  These
routines make it possible for the servers and raster lib to only have to
worry about a filename and a couple of file descriptors (all the socket
structures are handled transparently).

> How do the clients/servers know which sockets to use? With fifos they
> are included in the arguments, however with sockets I would think the
> display driver takes the initiative to register sockets which the
> clients look for, however that's pure speculation on my part.

It's done by "name".  That is, a routine in the aforementioned
"unix_socks.c" file, makes a file path using the server's name and the
current mapset temp file directory.  It's very simple.  "d.mon" executes
each server process with a certain name (like "x0"), so the server just
looks at argv[0] to find out its "name" and calls G_sock_get_fname(me)
to get a full path for the call to G_sock_bind().  The raster lib does a
similar thing.  It just queries the "environment" for the name of the
currently active display driver (set by d.mon), calls
G_sock_get_fname(driver) and then G_sock_connect(path) to get a file
descriptor.  After that, it's all read() and write() until a close() or
the process exits.  Sockets are duplex, so only one file descriptor is
needed for both reading and writing (server's have two, a listening
descriptor and, after a successful G_sock_accept(), a connected
descriptor).

> My code uses functions in connect.c and SWITCHER.c in GRASS 5.0 to
> check the validity of fifos and to then 'connect' to them (read/write
> to them). The functions are used/copied verbatim, I don't change the
> initial dispatch method (which is currently calling a bunch if inline
> drawing functions). If your sockets implementation is similar to the
> fifo implementation I should be able to support both methods easily.

Pretty much all of the code in connect.c is usused/unnecessary with the
sockets set-up (at least, I don't use it).  It is the source of some
read() blockage that is one of the many places where a blocked read()
call makes it impossible to handle Xevents like Expose.

> I hope nobody is adding functions to the display driver function set
> in 5.1. As soon as I support the current set I'll post the functions I
> plan to add for layers etc. Hopefully no parallel work is going on.

I think we really need a function for plotting polygons with holes.
I've been working on a major work-around in d.area, having now written
some 1300 lines of code.  Modules should not have to go through such
contortions...

> (FYI what I actually do is use two executables. One acts as the
> display driver and tells the primary application which fifos to use to
> create a new display canvas document. The display driver initializer
> knows the primary app is running because it vends an object as a
> server. I have to do this because fifos are passed as command
> arguments instead of some runtime method which you may or may not be
> using with sockets. Either way I can allow the primary application to
> create or accept sockets or use the prior method if it's more like
> fifos and command line arguments. I hope that made sense.)

Are you saying, instead of having 2 programs involved, we'll now have
three?

In the long run, my personal opinion is we should move toward a regular
GUI interface for interactive display usage.  Parallel to this should be
an effort to expand and improve the capabilities of ps.map.  This way, in
theory, we should be able to develop better interactive display tools,
while having a good avenue for script-based generation of maps.  The
CELL and PNGDrivers are serviceable, but it makes more sense to me to
have a high level mapping language/command set and possibly have other
targets than PostScript.

I know only enough GUI stuff to get me in trouble, but given the wide
number of platforms we wish to support, I think Tk is the only viable
solution.  I've seen some really nice Tk apps and I believe it could
handle pretty much all we want.  

The basic architechture of the display code is just wrong for
interactive use.  It's just not designed to handle all kinds of random
things that users do.  I don't have much experience here, but it seems
the design needs to be more action-response oriented using callbacks or
some other method.

-- 
Eric G. Miller <egm2 at jps.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'