Re: API, was: Question re HIP dependency & some architectural considerations

Hi, Iljitsch

My confusion remains constant across threads, apparently...
>
> At this juncture, I'll observe that we have T/TCP (TCP for
> transactions) which pretty much eliminates the delay caused by the
TCP
> three way handshake, but T/TCP is often badly implemented, and, as
far
> as I can tell, extremely rarely used. Same goes for HTTP session
> keepalive/reuse.

Agree on T/TCP, confused on HTTP persistent connections. I'm just
caught on "badly implemented and extremely rarely used".

T/TCP was a brilliant idea that fell into the Grand Canyon of
security - the lack of a three-way initialization handshake opened
T/TCP up to sequence number guessing attacks. I don't have a
mathematical proof of this, but the security community basically
considered T/TCP impossible to secure. So, definitely, "extremely
rarely used".

My experience with HTTP browsers and servers is that early
implementations had problems (off-by-one errors in object sizes that
deadlocked transfers, bad interactions with HTTP/1.0 proxies that
didn't support persistent connections), and after these problems were
fixed, some server operators continued to run "Connection: close" mode
to free up resources for new connections, but the biggest issue I've
seen the last few years is that content may be spread across so many
servers that browsers don't try to keep all the connections open.

Got a pointer to other current problems?

Spencer