[Server-devel] Network transparent XS services - limitations and alternatives
C. Scott Ananian
cscott at laptop.org
Tue Aug 26 11:39:30 EDT 2008
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
> 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.
( http://cscott.net/ )
More information about the Server-devel