https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6755
--- Comment #19 from Cristian Constantin <const.crist@xxxxxxxxxxxxxx> 2012-01-27 12:34:18 PST ---
(In reply to comment #13)
> > cristian: yes, right. conversations are stored in the linked list; sorry, it was my mistake saying frames.
>
> Then you probably also didn't mean to say "frames" in "slow loading/processing
> of conversations with over 500k frames." If you truly have over 500k UDP or
> TCP packets going between {host1,port1} and {host2,port2}, that should result
> in one conversation, and if that's the only conversation, the linked lists
> should be very short and not see this problem. If you have a *lot* of
> conversations between {host1,port1} and {host2,port2}, then the linked lists
> will be longer, and you'll see this problem.
>
cristian: I think I understand now what you mean.
this would appear in the following case:
a. the tuple {host1,port1,host2,port2} is _always_ used for
the tcp communication between host1 and host2
b. tcp connection is on and then off and so on(i.e. there are multiple initial
SYNs with different initial sequence numbers and that's when conversation_new()
is called for tcp, right?)
please correct me if I am wrong.
I cannot tell exactly which application would have such a behaviour
over tcp (not the case for the http client/server communication since
the client port is usually randomly chosen by the kernel).
I didn't test the patch with such a scenario, yet.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.