Re: [HACKERS] some more rambling on the new fe/be communication

Brett McCormick <brett(at)work(dot)chicken(dot)org> writes:
> I'll have to familiarize myself with the new frontend code, but I plan
> on making a similar patch for 6.4 (as we'll also want SSL connections
> with that).

This seems like a reasonable plan, if you need SSL *now* and not after
6.4 is released. But:

> I am tempted to hold off on that once I get my current
> SSL up to snuff and instead work on perl stored procedures, as I feel
> that is more valuable (and will also do more to familiarize myself
> with the code).

I'd recommend you do the 6.4 version of the patch first, while it's
still fresh in your mind. AFAIK, stored procedures are a completely
different area of the system; you won't learn anything there that is
relevant to the FE/BE protocol.

> On Thu, 4 June 1998, at 13:23:17, Tom Lane wrote:
>> Yes. Data on a connection is data; there's no way for the far end to
>> tell what syscall or library was used to collect and send the data.
>> (The far end might not even be Unix or C based, after all.)

> What about OOB data? is that just data as well?

As far as the TCP protocol is concerned, yes. A lot of libraries that
you might want to use do not have an API that accounts for the separate
"OOB" channel within one TCP connection, so it may be difficult or
impossible to get at TCP's OOB facility from within a particular
programming environment. But that's not exactly a cross-environment
compatibility problem, it's just a missing feature in a library API.
Any two implementations that both handle OOB should be able to
communicate.

> I'm sure an SSL connection can be select()'d, and it does support
> non-blocking recv (I think that's the only way). I think it does
> block, however, if it doesn't get a full SSL "packet" (or whatever the
> appropriate term may be).

Hmm ... I don't know enough about SSL to know if this is really a
problem, but your comment raises warning flags in my head. This
needs investigation.

regards, tom lane