Hi everyone, As I know, tshark is a single threaded application so that it cannot use multiple cores to increase speed. I'm currently working with its source code and have some questions:
Please help if you have any idea for these question. Thank you very much. asked 17 Oct '16, 00:11  hoangsonk49 edited 17 Oct '16, 00:40 |
2 Answers:
First thing, the thing you are talking about is actually the dissection engine. This engine is shared between tshark and wireshark, so there's no difference there. The additional analysis features differ, these are part of the programs. Packet dissection is (by nature) a sequential task. Information from packet N is used to determine characteristics of packet N+1. That aspect makes packet dissection not very suitable for multithreading. The first dissection run is indeed done sequentially. In Wireshark, when clicking a packet the packet is redissected (for details) using this information. But that is only that packet, so not that much work. This basically covers 2, 3 and 4. As for 1 this depends on how many CPU cycles you can trow at it, and memory and I/O bandwidth, and the extensiveness of packet dissection being done. So it's really hard to give numbers on this. answered 17 Oct '16, 03:01  Jaap ♦ edited 17 Oct '16, 03:08  sindy Thanks for your answer, Jaap (17 Oct '16, 18:16) hoangsonk49 |
A few more thoughts (in addition to what Jaap and Anders said)... Yes, analyzing packets is by nature fairly sequential. But it should be possible to parallelize it to some extent. For example, it should be possible to send processing of packets for a given TCP session off to a separate thread (e.g., look at source and destination IPs and ports and put that message on a queue for a thread dedicated to that session). Assuming you've got multiple sessions you'll use multiple threads. BUT you couldn't do this with Wireshark's source code--at least not in its current state. There are way too many global variables and other thread-unsafeness in the dissectors. There has been a little bit of general work to eliminate this kind of thing but I think it's mostly done on principle with only a slight eye towards eventual thread-safeness. answered 17 Oct '16, 06:25  JeffMorriss ♦ Thank you Jeff :) (17 Oct '16, 18:16) hoangsonk49 |
The main problem with multi-threading is that some packet dissection relays on the information from previous frames so these packets need to be dissected in order to have the right results.
Thank Anders for the answer of question 2 and 3. How about the others? Please help if you have any idea. Thank you.