--
You received this message because you are subscribed to the Google Groups "PcapPlusPlus support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pcapplusplus-sup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pcapplusplus-support/b34a3575-c20c-48a1-996f-84e95477832c%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "PcapPlusPlus support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pcapplusplus-sup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pcapplusplus-support/7ac19968-945b-4d70-b6a5-82fd32f25bd9%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pcapplusplus-support/CAGATen4JJmk7_w5mFpMCScA0XRMJkosJ%3DeZQZhdoC_FwcTWtYQ%40mail.gmail.com.
On Fri, Apr 10, 2020 at 12:52 AM Dk Jack <dnj...@gmail.com> wrote:
as I mentioned, for passive capture, the two choices are span port (port mirroring) or a network tap device. Span ports are cheap but come with problems. They'll work if the traffic volumes are low. Even then they are susceptible to introducing packet reordering. I've seen request/responses packets get re-ordered even when I was manually making curl requests and capturing. Besides using a tap device, the choices are limited.
On Thu, Apr 9, 2020 at 11:35 PM Dk Jack <dnj...@gmail.com> wrote:
Depends on how the capture is happening? If the capture is happening on a sending or a receiving or an in between inline system, then this will not be a problem. However, if the capture happens using a span port (i.e. port mirroring etc), then you may run into issues even your network is good. Passive capture devices like network taps will not have these problems. See the following link--
On Thursday, April 9, 2020 at 4:07:07 AM UTC-7, mars zhang wrote:HiTcpReassembly.h said* - If the missing data doesn't arrive until a new message from the other side of the connection arrives or until the connection ends - this will be considered as missing data and the* queued data will be sent to the user, but the string "[X bytes missing]" will be added to the message sent in the callbackwhy so many [X bytes missing] packets? My network is very good。How to avoid that?
You received this message because you are subscribed to the Google Groups "PcapPlusPlus support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pcapplusplus-support+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pcapplusplus-support/7ac19968-945b-4d70-b6a5-82fd32f25bd9%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "PcapPlusPlus support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pcapplusplus-support+unsub...@googlegroups.com.
HiMay I use PcapPlusPlus with DPDK under windows? (https://www.dpdk.org/blog/2019/07/15/dpdk-releases-v19-05-introduces-windows-support/ )
在 2020年4月11日星期六 UTC+8下午3:43:37,PcapPlusPlus Support写道:
On Fri, Apr 10, 2020 at 12:52 AM Dk Jack <dnj...@gmail.com> wrote:
as I mentioned, for passive capture, the two choices are span port (port mirroring) or a network tap device. Span ports are cheap but come with problems. They'll work if the traffic volumes are low. Even then they are susceptible to introducing packet reordering. I've seen request/responses packets get re-ordered even when I was manually making curl requests and capturing. Besides using a tap device, the choices are limited.
On Thu, Apr 9, 2020 at 11:35 PM Dk Jack <dnj...@gmail.com> wrote:
Depends on how the capture is happening? If the capture is happening on a sending or a receiving or an in between inline system, then this will not be a problem. However, if the capture happens using a span port (i.e. port mirroring etc), then you may run into issues even your network is good. Passive capture devices like network taps will not have these problems. See the following link--
On Thursday, April 9, 2020 at 4:07:07 AM UTC-7, mars zhang wrote:HiTcpReassembly.h said* - If the missing data doesn't arrive until a new message from the other side of the connection arrives or until the connection ends - this will be considered as missing data and the* queued data will be sent to the user, but the string "[X bytes missing]" will be added to the message sent in the callbackwhy so many [X bytes missing] packets? My network is very good。How to avoid that?
You received this message because you are subscribed to the Google Groups "PcapPlusPlus support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pcapplusplus-sup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pcapplusplus-support/7ac19968-945b-4d70-b6a5-82fd32f25bd9%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "PcapPlusPlus support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pcapplusplus-sup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pcapplusplus-support/CAGATen4JJmk7_w5mFpMCScA0XRMJkosJ%3DeZQZhdoC_FwcTWtYQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "PcapPlusPlus support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pcapplusplus-sup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pcapplusplus-support/88158cad-4d86-44e7-94fc-dbe51c6a2543%40googlegroups.com.