Re: The future of ICP_OP_HIT_OBJ

My understanding of the *motivation* of ICP_HIT_OBJ was traffic minimization
combined with delay minimization. If you can send a positive response and
in doing so can send the content anyway, it was worth doing on both counts.

So if you have a persistant TCP connection between the neighbours, most if
not quite all of the delay issues go because the TCP pipe exists so the
setup costs are 'shared' across the lifetime of the connection in question
(many thousands of events?) and you're left with traffic minimization.

Is it worth the downsides of UDP to achieve one goal? about all you save
timewise is the ICP_HIT -> HTTP request/response delay.

Now if you can just SEND the outcome by HTTP instead of having to be asked
for it, you kill that part as well, but it breaks the client-server nature
of the HTTP pipe in question.. or does it? is a persistant connection used
by both neighbours to initiate transfers? If so, logistically how hard would
it be to make getting an ICP_HIT prime the recipient to expect the data on
the TCP pipe to follow?

cheers
        -George

--
George Michaelson         |  DSTC Pty Ltd
Email: ggm@dstc.edu.au    |  University of Qld 4072
Phone: +61 7 3365 4310    |  Australia
  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au