On 1/14/07, Guy Harris <guy@xxxxxxxxxxxx> wrote:
rmkml wrote:
...
> and maybe add memory parameter alloc limit ? (icmp/udp/ipproto and others)
We could, but, at least for me, if the default for that parameter
weren't "infinity", I'd change it to infinity in my configuration.
The biggest problem is probably reassembly. In your case, if you were
doing a *single* wget, note that the *entire* contents of the file being
downloaded will be reassembled. A limit on the amount of data that can
be reassembled - with the reassembly code ideally just discarding the
code and making the tvbuff with the reassembled data short (i.e., its
reported length would be the total amount of data to be reassembled, and
its data length would be the amount of data it kept), so that the HTTP
dissector doesn't restart dissecting in the middle of the file being
downloaded - would probably handle that.
If/when we complete converting all memory management into ep_/se_
style allocations it would become much easier to do this.
We could then for example do things like :
reset the se_heap back to zero once it has reached X number of bytes
in total allocation.
Of course, things such reassembly, request/response tracking wouldnt
work for things spanning across one such "reset memory" boundary but
neither do those features work if the file is just too large you have
to first chop it up into smaller ones with editcap.
