Re: The future of ICP_OP_HIT_OBJ

Better late than never... :)

#define quoting(Duane Wessels)
// There are a number of factors to consider in deciding if HIT_OBJ
// is a good thing. For example:
//
// - ICP is sent over UDP. UDP does NOT have flow-control
// and could cause congestion.
//
// - Fragmentation of UDP is considered harmful. If a single
// fragment is lost, the entire datagram is lost.

Because of these two factors, I was thinking about ICP over TCP
some time ago. I wish I had the time to study this more.

The benefits would be a lossless communication between servers, and
reduce congestion. Also, this could enable some kind of authentication
between proxies. Since most ICP requests are far smaller than the
typical MSS, grouping would also occur.

The problem is that the TCP window could colapse and the ICP performance
would be bad. But this only happens on congestioned environments,
when UDP is already a problem. Somebody may think of ACKs as problems,
but TCP is piggybacked, so it should not be that harmful.

This would also serialize ICP between two single servers. Maybe using
more than one single TCP stream could allow faster response and reduce
the serialization problems. Also, a smart algorithm could detect
buffer fullness and avoid more ICP to that socket.

And most important is an algorithm to reconect broken streams, of
course. But this must be the easier part.

                                        Jonny

PS: With ICP/TCP, ICP_HIT_OBJ probably must not exist. :)

--
Joao Carlos Mendes Luis			jonny@gta.ufrj.br
+55 21 290-4698				jonny@coppe.ufrj.br
Universidade Federal do Rio de Janeiro	UFRJ/COPPE/CISI
PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2  83 5F E3 26 BF 0F EA 67