Thread

comm patch & ssl patch

Brett McCormick <brett@work.chicken.org> — 1998-05-29T03:13:46Z

I've decided to make two separate patches, a "communication" patch to
clean up the fe-be communication (to be submitted for inclusion) and
then a separate SSL patch.  this is good because, if approved for
merging, will clear up a lot of inconsistency regarding the io
communication in the backend and frontend.  it also has the added
benefit of making my SSL patch less hack-ish.

I haven't heard much from you guys regarding the backend
communication, but I figure if I make a good patch that doesn't
interfere and has positive changes, what have we got to lose.

I'm considering going as far as making it more even more modular so
that it is easier for other people to take advantage of that, but I'm
not sure how anyone feels about that.  First things first I guess.

btw, i'm still planning on implementing stored procedures in perl.
i'd like to gauge the relative interest of these two projects so I can
decide how to spend my time.

Re: [HACKERS] comm patch & ssl patch

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-05-29T03:36:52Z

> I haven't heard much from you guys regarding the backend
> communication, but I figure if I make a good patch that doesn't
> interfere and has positive changes, what have we got to lose.

My impression is that the frontend/backend comm has been less-than-ideal
for some time. Someone submitted patches to fix the reversed network
byte ordering (Postgres sends little-endian using home-grown versions of
the big-endian ntoh/hton routines) but got discouraged when they didn't
quite work right on mixed-order networks.

Anyway, it would be great if a few people would take an interest, as you
have, in cleaning this up. The OOB discussion touches on this also, and
if there are non-backward-compatible changes for v6.4 then you may as
well clean up other stuff while we're at it.

For something as fundamental as client/server communication we should
probably have a few people testing your patches before applying things
to the source tree; I'd be happy to help (but can only test on a
little-endian machine) and Tatsuo in Japan has a mixed-order network
which he has used for extensive testing in the past.

                        - Tom

Re: [HACKERS] comm patch & ssl patch

Matthew N. Dodd <winter@jurai.net> — 1998-05-29T04:00:17Z

On Thu, 28 May 1998, Brett McCormick wrote:
> I'm considering going as far as making it more even more modular so
> that it is easier for other people to take advantage of that, but I'm
> not sure how anyone feels about that.  First things first I guess.

You have my blessing.  (For as much as it counts for anything.)

:)

/* 
   Matthew N. Dodd		| A memory retaining a love you had for life	
   winter@jurai.net		| As cruel as it seems nothing ever seems to
   http://www.jurai.net/~winter | go right - FLA M 3.1:53	
*/

Re: [HACKERS] comm patch & ssl patch

Brett McCormick <brett@work.chicken.org> — 1998-05-29T04:21:04Z

On Fri, 29 May 1998, at 03:36:52, Thomas G. Lockhart wrote:

> Anyway, it would be great if a few people would take an interest, as you
> have, in cleaning this up. The OOB discussion touches on this also, and
> if there are non-backward-compatible changes for v6.4 then you may as
> well clean up other stuff while we're at it.

the changes I propose are completely backward compatible, as far as
the network communication goes.  What other compatibility aspects
should I be worried about?

Can you fill me in on the OOB discussion?  As far as I know, we were
planning on using it for the synchronous notification, but it turns
out we can't because unix sockets won't support it.  So now we're
thinking of opening another connection to the postmaster (?) to send
the cancel message, along with some sort of authorization cookie.
We're now trying to determine the best way of making it secure, right?
I wouldn't be too worried about it, really.  Postgres can't really
protect itself against packet sniffing.  If someone can connect to
your database and delete all your tables, why are we worried about
being able to send a cancel message?

Hass this list been especially quiet lately?  Or am I not up-to-date
on the new list scheme?

> For something as fundamental as client/server communication we should
> probably have a few people testing your patches before applying things
> to the source tree; I'd be happy to help (but can only test on a
> little-endian machine) and Tatsuo in Japan has a mixed-order network
> which he has used for extensive testing in the past.

I agree wholeheartedly.  BTW, it passes the regression tests.  Not
that this means it should have the living daylights tested out of it,
but it is a promising sign.

Another question: how does each backend end up exiting?  (I'm about to
find out).  From what I can tell, when the backend receives the 'X'
character from the front-end (meaning: front-end exiting), it calls
pq_close, which closes the file pointers and sets them to null.
Then it proceeds to call NullCommand, which signals the end of a response.
But, of course, it can't do this, because its file pointers are gone.
This is inside of an infinite for(;;) loop.

I guess I'll answer my own question.  On the next iteration of the for
loop, ReadCommand is called, which in turn calls SocketBackend, which
tries to read a character.  If this fails (returns EOF) it decides to
exit.  It would seem more appropriate to exit after pq_close is called
(but not in pq_close).

comments?

Re: [HACKERS] comm patch & ssl patch

Bruce Momjian <maillist@candle.pha.pa.us> — 1998-05-29T14:25:57Z

> 
> On Fri, 29 May 1998, at 03:36:52, Thomas G. Lockhart wrote:
> 
> > Anyway, it would be great if a few people would take an interest, as you
> > have, in cleaning this up. The OOB discussion touches on this also, and
> > if there are non-backward-compatible changes for v6.4 then you may as
> > well clean up other stuff while we're at it.
> 
> the changes I propose are completely backward compatible, as far as
> the network communication goes.  What other compatibility aspects
> should I be worried about?
> 
> Can you fill me in on the OOB discussion?  As far as I know, we were
> planning on using it for the synchronous notification, but it turns
> out we can't because unix sockets won't support it.  So now we're
> thinking of opening another connection to the postmaster (?) to send
> the cancel message, along with some sort of authorization cookie.
> We're now trying to determine the best way of making it secure, right?
> I wouldn't be too worried about it, really.  Postgres can't really
> protect itself against packet sniffing.  If someone can connect to
> your database and delete all your tables, why are we worried about
> being able to send a cancel message?

Yes, you are correct.
> I agree wholeheartedly.  BTW, it passes the regression tests.  Not
> that this means it should have the living daylights tested out of it,
> but it is a promising sign.
> 
> Another question: how does each backend end up exiting?  (I'm about to
> find out).  From what I can tell, when the backend receives the 'X'
> character from the front-end (meaning: front-end exiting), it calls
> pq_close, which closes the file pointers and sets them to null.
> Then it proceeds to call NullCommand, which signals the end of a response.
> But, of course, it can't do this, because its file pointers are gone.
> This is inside of an infinite for(;;) loop.
> 
> I guess I'll answer my own question.  On the next iteration of the for
> loop, ReadCommand is called, which in turn calls SocketBackend, which
> tries to read a character.  If this fails (returns EOF) it decides to
> exit.  It would seem more appropriate to exit after pq_close is called
> (but not in pq_close).

Any cleanup you can do would be helpful.  Sounds like you are on-top of
it.


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