Network transparent XS services - limitations and alternatives

[Martin Langhoff]

On Wed, Aug 27, 2008 at 3:39 AM, C. Scott Ananian <cscott at laptop.org> wrote:
> I prefer a stronger assumption: network services are all based on cachable HTTP.

Implementations of cacheable HTTP - both on the server and client -
are *caching*, not replacing.

We want to do partial replacement/substitution of resources, and we
are going to face a ton of bugs.

>> I agreed - even though I know that most TCP/IP protocols don't really
>> work that well, at least we could fake it with HTTP, in the great
>> tradition of transparent HTTP proxies.
>
> I have no objection to specifying a non-transparent proxy either, but
> it must be autoconfiguring so the network doesn't break when the
> laptop goes home.

Agreed. That's why I mentioned proxy autoconf protocols :-)

>>  - Limited to a few protocols. HTTP works. HTTPS does not.
>
> HTTPS has many problems.  None of the basic XO protocols use HTTPS.

Will we never care for end-user privacy?

>>  - At the protocol layer you mask a whole host:proto - not specific
>> resources, unless you have a very smart proxy. In the case of HTTP, we
>> can use squid+jesded to serve locally "just" some urls.
>
> So this isn't a problem.

*Only* for HTTP. It is a problem for rsync, hence the --server patch
you saw from me. And it is still a problem for HTTP as per below...

>>  - Clients still perform DNS lookups and attempt to establish direct
>> connections. This breaks really badly in disconnected scenarios - DNS
>> does not resolve, so the client will never request the URL via the
>> proxy. We can serve fake DNS names pointing to the XS, but that is
>> very ugly hack with innumerable downsides.
>
> This is a good reason to provide an explicit HTTP proxy, which
> explicitly handles these issues.

Agreed.

> But preseeding a offline DNS cache in the same way we preseed a web
> cache seems an entirely reasonable solution, that will allow many
> things to "just work".

It will break a lot of stuff. For starters

 - In a connected scenario, faking DNS allows us to mask something
like rsync, but it breaks all other services from that host. And the
rsync masking is all-or-nothing too, not a per-path thing.

 - In a disconnected scenario, faking DNS affects the whole 'host'
entry. We just don't know what services we might be masking that may
not react well to being pointed at the XS.

And most importantly, we miss out on the opportunity of having smart
client code. XS aware interactions can be smarter as they can make
stronger assumptions about locality and network availability.

We are already doing this with Telepathy.

> Again, it seems like you need an offline DNS solution.  Many legacy
> applications will assume they can resolve a DNS name to an address; it
> seems best to let them do this.

Let me clarify -- I've setup my first split-horizon DNS in 1998. I'm
not afraid of it, or unfamiliar with it.

>> So this is a heads up - in summary
>>
>>   We cannot assume network transparency on XS services.
>
> I totally disagree.

Aha, so can you please explain a suitable alternative to

 -  masking specific host:proto:resource paths across protocols --
while connected -- without affecting other resources and protocols on
that host?

 - how do we do the above in a disconnected scenario, without the
issues of clients assuming that the XS provides *all* the services of
the masked host?

cheers,




m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff