
I'm rewriting my SSL for patch so it's a little less messy, and I've
come across something interesting.

What I've done is replaced Pfin,Pfout and Pfdebug with a struct called
PGcomm.

pqcomm.c had Pfin/Pfout/Pfdebug as "global" variables.  some other c
files have "extern" entries for these variables.  the in/out funcs in
pqcomprim.c take a FILE * as an argument instead of the extern
approach.  I'm not sure there are any cases where the FILE * passed
differs from the one in the global Pfin, but to maintain consistency,
I haven't changed it.  So the functions in pqcomm.c still access the
global copy of the PGcomm struct (my replacement for
Pfin/Pfout/Pfdebug) and pqcomprim.c still takes a PGcomm * as an
argument.  There are actually little [f]read/[f]write system calls in
pqcomm.c, most of the communication takes place by calling pqcomprim.c
functions.

the reason i'm writing this mail are twofold, one is: are the
developers interested in merging my input/output changes into the
distribution.  this has the benefit of making the io a little more
coherent, right now it seems sort of patched together, read/write
mixed with fread/fwrite, functions that do the same thing but take
different arguments, fread/fwrite in the actual code instead of
calling an appropriate function.  this seems like a good idea to me.
we could also define an interface for implementing transport layers,
so my patch could be an add-on module.

so, the interesting part is this: there is a call to pq_putstr after
the client has disconnected.  so, when I exit out of psql, I get an
error (with my patch) whereas before, if fputs gets a NULL pointer, it
doesn't signal an error for some reason.  I've modified my patch to
match the behavoir, but it does seem a little odd.  I will try to find
the place this is being called from, as it does not seem like a good
thing.

Let me know if I need to clarify.

Wed, 27 May 1998 16:05:00 -0700 (PDT)
Brett McCormick <brett@work.chicken.org>
backend/frontend communication
Brett McCormick <brett@work.chicken.org> writes:

> I'm rewriting my SSL for patch so it's a little less messy, [...]

Does this mean that you're adding a facility for an encrypted data
stream between server and clients?  If so, great!  Are you adding this
in such a way that other mechanisms than SSL can be facilitated?  I'd
like to take a shot at adding Kerberos IV encryption to your model...

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"

28 May 1998 07:40:37 +0200
Tom Ivar Helbekkmo <tih+mail@Hamartun.Priv.NO>
Re: [HACKERS] backend/frontend communication
On , 28 May 1998, at 07:40:37, Tom Ivar Helbekkmo wrote:

> > I'm rewriting my SSL for patch so it's a little less messy, [...]
> 
> Does this mean that you're adding a facility for an encrypted data
> stream between server and clients?  If so, great!  Are you adding this
> in such a way that other mechanisms than SSL can be facilitated?  I'd
> like to take a shot at adding Kerberos IV encryption to your model...

Once the patch is rewritten, yes, all fe/be communication will take
place in two functions, pq_read and pq_write.  It'll take a little
more to make it completely modularized (once bruce removes the exec()
it will make things much better -- as it is the SSL connection must be
renegotiated at that point) but I think it is worth the effort.  I may
go as far as to allow pluggable transport mechanisms and
authentication.

It's a work in progress.  The info page is at
http://www.chicken.org/pgsql/ssl/

It details some of the changes I plan to make, as well as a short
description of the patch and how I feel about the fe/be communication.
However, it is probably poorly written, so I should probably change
that.

I warn against using it at this point -- libpq is the only interface
guarunteed to work, which means no perl interface without some ugly
hacking.  This will change.

Wed, 27 May 1998 23:17:40 -0700 (PDT)
Brett McCormick <brett@work.chicken.org>
Re: [HACKERS] backend/frontend communication
On Wed, 27 May 1998, Brett McCormick wrote:

> the reason i'm writing this mail are twofold, one is: are the
> developers interested in merging my input/output changes into the
> distribution.  this has the benefit of making the io a little more
> coherent, right now it seems sort of patched together, read/write
> mixed with fread/fwrite, functions that do the same thing but take
> different arguments, fread/fwrite in the actual code instead of
> calling an appropriate function.  this seems like a good idea to me.
> we could also define an interface for implementing transport layers,
> so my patch could be an add-on module.

	Go for it...I like the thought of simplifying the code, which this
sounds like it will do.

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Fri, 29 May 1998 19:21:58 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] backend/frontend communication
> 
> On Wed, 27 May 1998, Brett McCormick wrote:
> 
> > the reason i'm writing this mail are twofold, one is: are the
> > developers interested in merging my input/output changes into the
> > distribution.  this has the benefit of making the io a little more
> > coherent, right now it seems sort of patched together, read/write
> > mixed with fread/fwrite, functions that do the same thing but take
> > different arguments, fread/fwrite in the actual code instead of
> > calling an appropriate function.  this seems like a good idea to me.
> > we could also define an interface for implementing transport layers,
> > so my patch could be an add-on module.
> 
> 	Go for it...I like the thought of simplifying the code, which this
> sounds like it will do.
> 

I also encourge you to try and improve the handling of the variables
that you mentioned.  You can use ctags and mkid (see developers FAQ). 
That makes it easy.  I have noticed the inconstency, where some were
passed, and others were global, and could not figure out what they were
all used for.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Fri, 29 May 1998 23:52:24 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] backend/frontend communication