# tcp contents

**URL:** <https://community.zeek.org/t/tcp-contents/637>\
**Category:** Zeek\
**Created:** [November 30, 2004, 5:12pm UTC](https://community.zeek.org/t/tcp-contents/637 "2004-11-30T17:12:25Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Vern](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/vern/32/630_2.png) [@Vern](https://community.zeek.org/u/Vern)\
**Post date:** [November 30, 2004, 5:12pm UTC](https://community.zeek.org/t/tcp-contents/637/1 "2004-11-30T17:12:25Z")

</div>

> 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)  
> or  
> 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.

&nbsp;&nbsp;&nbsp;&nbsp;Vern

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\
**Post date:** [May 6, 2022, 3:37pm UTC](https://community.zeek.org/t/tcp-contents/637/2 "2022-05-06T15:37:15Z")

</div>