| -----Original Message-----
| From: Loïc Minier
|
| Ronnie Sahlberg - Mon, Oct 20, 2003:
|
| > Othervise, Imagine how surprised an innocent user would be
| when his Ethereal
| > completely hangs when
| > he loads a huge NFS over TCP capture with many many
| READ/WRITEs in it. :-)
|
| Yes, Ethereal's default seems logical to a developper, but it's
| disappointing for an user when he turns on
| TCP-desegmentation and forgets
| IP-reassembly for example. The same thing happens when he'd
| like to see
| a protocol running atop TCP reassembled but forget
| TCP-desegmentation.
| One could think the Preferences miss some logic, but it's really a
| difficult problem because one protocol can run atop of a lot of other
| protocols. May be dissectors of a level noticing the users wants
| desegmentation/reassembly should be able of requiring their
| lower level
| protocol to turn on desegmentation/reassembly too.
|
| As a temporary workaround, what do you think of including a hint
| regarding "IP reassembly" or "TCP desegmentation" in the comments of
| the reassembly options for all dissectors providing desegmentation?
Maybe we should compute reassembly information on the 1st
pass of reading a capture, so that we have an approximate
idea on the amount of memory we'll have to allocate again
for the actual reassembly.
Or we could enhance the tvbuff and reassembly code so that it
doesn't always duplicate memory at reassembly, but works with
linked lists that are hidden to the developer by the familiar
helper functions.
Regards,
Olivier