1

Is there any way of checking if data sent using winsock's send() or WSASend() are really delivered to destination?

I'm writing an application talking with third party server, which sometimes goes down after working for some time, and need to be sure if messages sent to that server are delivered or not. The problem is sometimes calling send() finishes without error, even if server is already down, and only next send() finishes with error - so I have no idea if previous message was delivered or not.

I suppose on TCP layer there is information if certain (or all) packets sent were acked or not, but it is not available using socket interface (or I cannot find a way).

Worst of all, I cannot change the code of the server, so I can't get any delivery confirmation messages.

Qantas 94 Heavy
  • 15,750
  • 31
  • 68
  • 83
miara
  • 320
  • 1
  • 5

2 Answers2

0

Not from the return to send(). All send() says is that the data was pushed into the send buffer. Connected socket streams are not guarenteed to send all the data, just that the data will be in order. So you can't assume that your send() will be done in a single packet or if it will ever occur due to network delay or interruption.

If you need a full acknowledgement, you'll have to look at higher application level acks (server sending back a formatted ack message, not just packet ACKs).

CoreyStup
  • 1,488
  • 13
  • 14
  • TCP protocol has acks, so TCP layer exactly know if other side received given part of sent message - isn't there any option of get this information? I know that acking whole message by other TCP stack doesn't mean reading it and processing by application, but I can assume its close enough. I cannot modify application protocol, as its third party server. – miara Jan 27 '11 at 07:04
  • That information is not propagated back up to the API, and as you said it doesn't mean that the server read it out of *its* buffers and processed it either. – CoreyStup Jan 27 '11 at 13:36
0

I'm sorry, but given what you're trying to achieve, you should realise that even if the TCP stack COULD give you an indication that a particular set of bytes has been ACK'd by the remote TCP stack it wouldn't actually mean anything different to what you know at the moment.

The problem is that unless you have an application level ACK from the remote application which is only sent once the remote application has actioned the data that you have sent to it then you will never know for sure if the data has been received by the remote application.

'but I can assume its close enough'

is just delusional. You may as well make that assumption if your send completes as it's about as valid.

The issue is that even if the TCP stack could tell you that the remote stack had ACK'd the data (1) that's not the same thing as the remote application receiving the data (2) and that is not the same thing as the remote application actually USING the data (3).

Given that the remote application COULD crash at any point, 1, 2 OR 3 the only worthwhile indication that the data has arrived is one that is sent by the remote application after it has used the data for the intended purpose.

Everything else is just wishful thinking.

Len Holgate
  • 21,282
  • 4
  • 45
  • 92
  • I know its delusional, but its impossible in this situation to get acks at application level. So in what way TCP stack could give me an indication on remote acks at protocol level? – miara Jan 27 '11 at 08:50