tcp contents

a. do you think I just didn't look hard enough at the data for a single file
(i.e., it wasn't working when I thought it was)
b. the single file approach would work "most of the time" or all of the time
if a connection (such as HTTP_Conn or SMTP_Conn) added a contents processor
derived from TCP_ContentLine. i.e. it would work if the TCP_Connection's
BuildEndpoints() method did something functionally equivalent to:

Closer to b. In particular, the internal mechanism uses seek() to find
the right position in the file, so two streams writing concurrently to the
same file will overwrite one anothe in unpredictable ways.

Obviously "most of the time" isn't good enough but it would explain why a
cursory check of the output looked valid.

Yes, that could well be the case.