Closed games130 closed 6 years ago
What commandline flags are you using? Are those packets > 8192 bytes? You can try to turn off deduplication with -dd=false
Depending on traffic load you better use af_packet with -t af_packet (make sure your interfaces are in promisc mode)
Since you use heplify-server you can try to send protobuf instead hep. Use -protobuf
Heplify-server is listening for tls too so try to use TLS instead of UDP with -nt tls.
If nothing of this helps I will add some debug lines into the code.
I am using the command line: ./heplify -i p1p1 -vlan & ./heplify -i p1p2 -vlan &
The packets are fragmented but less than 8192. Okay i will try the suggestion and feedback on the result once i have them.
Does this happen only for packets which are fragmented? Do you see some kind of regularity? Does all of those packets have a vlan tag?
okay, so far around 24 hours have pass, no encounter for the missing packet. I am currently using: ./heplify -i p1p1 -vlan -dd=false & ./heplify -i p1p2 -vlan -dd=false &
Will let it run for a few more days before final confirmation. Do you want me to feedback anything as to why the deduplication might cause this?
other question, any performance improvement in using protobuf vs HEP ?
Hi, you can lookup the dedup code in decoder.go. Ich put every message in the cache and compare them. This should probably be improved. If you have some ideas I am open for all of them ;)
Performance should be more or less the same. Protobuf encoding is faster than hep, hep decoder is faster than protobuf.
Protobuf is very usefull when you want to quickly create a hep client for different programming languages. You just need the proto file.
Biggest performance gain is to use af_packet. Keep in mind af_packet by default uses VLAN offloading so make sure your nic does not strip them.
It would also be interesting to explore if Apache Arrow and its columnar in-memory layout could provide us with a long-term, global performance booster on both ends of the tunnel
I was already interested in this from second 1. Right now the Go implementation is far far away from being useable for non numeric values but when it gets there I will evaluate it for sure.
Closing here because of no response.
I am using the latest heplify (self compile)
tcpdump done on server interface:
I am able to see the INVITE message from tcpdump capture on p1p2 but it was not encapsulated in HEP(seen from lo interface tcpdump).
I have tried to run heplify and select the pcap file to insert the SIP messages, it is working. So this means there is no problem with the encapsulation of the SIP into HEP. Probably something went wrong during the running of heplify.
The problem does not happen everytime (So far based on sample check most of the time it is working fine), i estimate mabye 1 or 2 packet are not encapsulated in 1 hour (I am only checking INVITE so cant say for sure if other messages are affected due to too many calls to manually check).
Any suggestion on how I can troubleshoot this?