Network transparent XS services - limitations and alternatives

[C. Scott Ananian]

On Tue, Aug 26, 2008 at 4:43 PM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
>> HTTPS has many problems.  None of the basic XO protocols use HTTPS.
>
> Will we never care for end-user privacy?

We do.  We just don't use HTTPS.  You should know better.

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

The upgrade server is a good example of how to make 'cachable' rsync
work.  Also, olpc-update should be able to use patches served over
http in the 9.1 time frame.

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

If we are connected, we should not be faking DNS.  Why would you want to do so?

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

No one says the XS has to answer for a service it doesn't know about.
Clearly, it shouldn't.

We are *not* just returning the XS's address in response for a request
for an inaccessible host.  See the discussion in [[Network
principles]].

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

Yeah, and how well is that working?

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

See above, and [[Network principles]].
 --scott

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