check the TCP ack

[ahmad r]

Hi
I am using TCP to send a bulk of data, code borrowed from tcp-bulk-send.cc. I wan to send data from node A to node B, and after that from node A to node C. B and C are reachable using some hops.
I want to send data from A to C, after getting the Ack from node B.(to prevent data collision)

Question:
1- how I can measure the time of receiving the ack from node B, after sending a bulk of data from node A to B?

Thanks for all your help

[Tommaso Pecorella]

Hi,

why don't you send a message from B to A when the transmission is finished ?

Sub-problem: how B knows the A has finished sending its data ?

Suggested solution type: don't send just zero-filled data. Start with a conventional message (you have to write its format) to say "Hey buddy, I'm gunna send you X bytes". When B has received X bytes it can reply with "Hey bro, I got 'em".

Cheers,

T.

[ahmad r]

Thanks T. :-). you helped me a lot during these days.

All nodes know about the size of data that they have to get from other nodes, so there is no problem.

the reason that I want to check receiving the Ack is that I have some packet loss(in My application, just one of the nodes can send the data). I think that the packet loss is due to the starting sending data to C(after finishing sending data to B without checking for Ack), while B is sending the Ack to A. and the Ack of B, and data of C will conflict. I think that it might be because of the packet loss. I tried to delay sending the data to C for 5 ms, which reduce the problem, but I still get some packet loss, around 1%. the B and C are multiple hop away of A.

Is there any other method to resolve the problem (conflict of Ack with the packet)?


Thanks

[Tommaso Pecorella]

Hi,

TCP will recover from the losses, so that's not a big issue.

If you want to lower them, first check where they are. You could have losses at PHY level (interference, collisions, etc), at MAC (queue overfull), ARP, etc.

Note that Bulk sending is a quite peculiar type of data generation: it will heavily stress all the Tx queues. As a consequence the drop could be there.

T.