Network transparent XS services - limitations and alternatives

[C. Scott Ananian]

On Mon, Aug 25, 2008 at 10:56 PM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> Discussing the activity installer/updater control panel and
> olpc-update (a few days before) one design assumption from the XO team
> was very strong: that network clients on the XO could just ignore the
> XS and attempt direct connections to the desired host and service. If
> the XS is there, the logic goes, it will transparently intervene.

I prefer a stronger assumption: network services are all based on cachable HTTP.

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

>  - Limited to a few protocols. HTTP works. HTTPS does not.

HTTPS has many problems.  None of the basic XO protocols use HTTPS.

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

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

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".  DNS already has all the infrastructure
required.

> Providing a "local activities installation service" for
> sugar-update-control is a good example. s-u-c can be told via a config
> file to look for a particular url, and the intention - as discussed
> with Scott - was to use the same URL for connected and disconnected
> schools. However, it just does not work in disconnected schools unless
> we completely fake DNS because the client wants a DNS entry for it.

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.

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

I totally disagree.
   --scott

-- 
 ( http://cscott.net/ )