Wireshark-bugs: [Wireshark-bugs] [Bug 6755] slow loading/processing of conversations with over 5
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6755
--- Comment #20 from Cristian Constantin <const.crist@xxxxxxxxxxxxxx> 2012-01-30 09:00:50 PST ---
(In reply to comment #17)
> (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 am lost, I do not understand anything anylonger :-(
> what do you mean by:
>
> "a *lot* of conversations between {host1,port1} and {host2,port2}"
>
> if it is the same protocol (udp for example), how exactly does
> wireshark distinguish between them?
>
> here are the statistics (Statistics/Conversation List/UDP) that I get after
> loading the packets (exported to csv):
>
> "Address A","Port A","Address B","Port B","Packets","Bytes","Packets
> A→B","Bytes A→B","Packets A←B","Bytes A←B","Rel Start","Duration","bps
> A→B","bps A←B"
> "x.x.x.x","8060","y.y.y.y","sip","585744","269717531","117183","59920148","468561","209797383","0.001429000","390.6763","1227003.52","4296086.31"
> "x.x.x.x","http-alt","y.y.y.y","sip","351456","205351530","0","0","351456","205351530","0.000301000","391.9773","N/A","4191090.31"
> "z.z.z.z","35009","y.y.y.y","sip","117167","66196754","117167","66196754","0","0","0.001366000","390.6763","1355531.41","N/A"
>
> what I saw during the profiling and in the code was that the list pointed
> to by "conversation->next" becomes really huge and there two bottlenecks:
> a. iterating over the list to get to the last element
> b. looking up an element based on the "conversation->setup_frame"
cristian: and now I know why as well...
I have traced the execution of wireshark while loading the capture leading to
this.
this is what I get:
#0 conversation_new (setup_frame=3, addr1=0x7fffffffb770,
addr2=0x7fffffffadb0, ptype=PT_UDP, port1=6001, port2=0, options=3) at
conversation.c:506
#1 0x00007ffff58bc901 in srtp_add_address (pinfo=<optimized out>,
addr=0x7fffffffb770, port=6001, other_port=0, setup_method=0x7ffff6022bb2
"SDP", setup_frame_number=3, is_video=0, rtp_dyn_payload=0x1ba28a0,
srtp_info=0x0) at packet-rtp.c:624
#2 0x00007ffff58bca03 in rtp_add_address (pinfo=<optimized out>,
addr=<optimized out>, port=<optimized out>, other_port=<optimized out>,
setup_method=<optimized out>, setup_frame_number=<optimized out>, is_video=0,
rtp_dyn_payload=0x1ba28a0)
at packet-rtp.c:673
#3 0x00007ffff58edb8f in dissect_sdp (tvb=<optimized out>,
pinfo=0x7fffffffc790, tree=0x1) at packet-sdp.c:523
so, basically, conversation_new is being called like this:
dissect_sdp -> rtp_add_address -> srtp_add_address -> conversation_new
special cases when the same (rtp) ip address, ports are being reused a lot of
times for setting up sessions can lead to the situation explained in the bug
description and create huge conversation lists.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
