eric writes:
> For this new year, I have 2 little suggestions for the new
> protocol. It should be interested to have a protocol which can be
> encapsulated in HTTP protocol.
> > * Some users have a net connection at work (who does not have one ?
> :) ) but they must go through a web proxy (apache, ...) to reach
> the net (like me@work) and most of the time, on these proxies, the
> command CONNECT is disabled, only GET and PUT are usable. It is
> interesting to reach such users because they may have big network
> connections (companies have money to pay big one :) ) and most of
> the time, this type of connection is less loaded during night
> (local time).

While that is a very interesting thought, I wouldn't bet that it would
work. Admittedly, I'm no HTTP expert, but as far as I understand it,
HTTP (especially when connected through restricting proxies) is
probably too sequential for the kind of duplex connection that a DC
implementation requires.

Possibly, if anything, you could set up two connections (ie. have the
client connect twice), and let those two act as two simplex
connections.

I would also imagine that some proxies let connections time out and
forcibly close the connection if the entire "page" hasn't been
recieved in a specified time. Since a DC implementation would keep the
connections open indefinitely, that is a problem.

> * Another suggestion linked to the previous one. Why not using HTTP
> protocol as user-to-user protocol ? it provides everything we need
> and can go through all proxies. Perhaps we can only use a subset of
> HTTP protocol because there is things we don't need.

That is IMHO a far more interesting option. As you say, it fits in
very well with the needs of a user-to-user protocol. Also, the HEAD
request happens to fit very well with just getting info on a file.

The problem, if anything, is that HTTP is a _huge_ definition. It
would have to be very well defined which subset of HTTP that has to be
implemented by all nodes.

Also, not that it's actually such big a deal, but if we don't use a
strict HTTP implementation for the hub<->client protocol, I don't
really think that it looks very nice having two different protocols
for one program. It would be nicer to use the same protocol both for
the hub<->client and the client<->client protocol.

Still, HTTP for the client<->client protocol is a very interesting
thought. I'd like more people to have their say.

Fredrik Tolf