Thread: backend/frontend communication
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.
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"
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.
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
> > 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)