Thread

1. backend/frontend communication

   Brett McCormick <brett@work.chicken.org> — 1998-05-27T23:05:00Z

   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.
   
   

2. Re: [HACKERS] backend/frontend communication

   Tom Ivar Helbekkmo <tih+mail@hamartun.priv.no> — 1998-05-28T05:40:37Z

   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"
   
   

3. Re: [HACKERS] backend/frontend communication

   Brett McCormick <brett@work.chicken.org> — 1998-05-28T06:17:40Z

   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.
   
   

4. Re: [HACKERS] backend/frontend communication

   Marc G. Fournier <scrappy@hub.org> — 1998-05-29T22:21:58Z

   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 
   
   
   

5. Re: [HACKERS] backend/frontend communication

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-05-30T03:52:24Z

   > 
   > 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)