How can I verify that a TCP packet received an ACK in C #?

After sending some tcp data using lock / non-blocking methods such as:

Socket.Send() or Socket.SendAsync() 

How can I find out that my data received an ACK message?

Can .NET know if TCP data has been sent successfully?

+4
source share
7 answers

The only way to know for sure is to implement some kind of confirmation at the application level. The TCP ACK packet is not displayed at the application level at all, so you need to use something more.

+11
source

You click on the other end.

Even if TCP has Acked, if the receiving side terminates (for good or bad reasons) before processing the message and affecting it, you still don’t know, so the only way to find out is to tell the other end.

+5
source

This information is not available in .net class libraries. I had the same considerations when I started working with this port scanner in C #. I used the .NET shell for libpcap (after installing the appropriate driver), SharpPcap ( http://sourceforge.net/projects/sharppcap/ ) to get this information. ACKs are received through the SharpPcap interface (transparently connecting the libpcap interface).

My application is NScanner Port Scanner / Sweeper, and you can find the code in codeplex, citing the fact that you just use the above library ( http://nscanner.codeplex.com/ ).

Hope I helped.

+3
source

"I'm trying to focus on how you can know when your data was received by the other side of the connection."

I think you need to know what type of application level protocol you are going to implement and what impact this has on application performance.

Take HTTP as an example of the Streaming like protocol. The server sends the data stream to the client. There is no longer an extra “ACK” application tier, and the server really doesn't care about when and how exactly its data stream arrives. This is very effective for high latency links.

Now compare this to SMB! Instead of streaming data, the data is divided into blocks. Each successfully transferred data block is marked at the application level. This gives you more control, however it effectively kills the protocol on WANs (check out “Bandwidth Delay Product”).

Given this, you can come up with your own design for your user protocol.

+2
source

The TCP layer will forward the packet until it receives a successful ACK.

Sending is blocked until this happens - SendAsync will not be blocked, and you can continue to process other material, while the TCP layer handles the sending of the packet.

0
source

If you are really sure that you need to know the level of your TCP connection, in addition to creating a TCP socket for sending, you need your application to use the winpcap API to view the raw traffic, you can set the filter only to receive packets IP-specific port combination that identifies your remote side.

There are several projects creating .NET wrappers for libpcap, for example here

0
source

I recommend using Pcap.Net .

You can sniff packages easily using this library in C #, and then easily check the package values.

You can also easily create and send packages.

0
source

All Articles