Adam Manock wrote:
Yes. The best solution would be for the ZEO protocol to support auth and crypto natively... The next best solution (while you wait) is to use CIPE ;-)
As far as I understand it, even regular TCP port forwarding is TCP over TCP and suffers from the unreliable carrier assumption causing excess (eg retransmit) traffic over a reliable channel.
Out of interest, could you elaborate that? I assume you mean port forwarding (without the TCP), which, AFAIK, just is a rewriting of some IP/UDP header information and some, uhm, forwarding. I am not aware of any encapsulation taking place. I quite sure that this isn't the case, because, after all, we can talk to a "normal" tcp/udp server on the ipaddress:port which we forward to. We can also port forward udp-traffic. SSL then adds another layer between transport and application, but it explicitly needs a reliable transport protocol underneath (e.g. TCP).
Consider: host <--TCP--> local interface <--TCP tunnel--> local interface <--TCP--> host host <--TCP--> virtual loopback interface <--TCP--> host
In this common port forwarding scenario, the SSH or SSL tunnel creates a virtual single loopback interface that the two hosts use to talk to each other, using TCP. The transport that joins these two physical interfaces to create one virtual loopback interface is also TCP. Therefore it's TCP over TCP
No, it isn't. You can use something like stunnel to https-"enable" non-https capable http-clients, stunnel -c -d 80 -r ssl-server:443 now go to http://localhost Try it, it's fun ;-). cheers, oliver