Understanding socket.Send() with TCP and confirmation

[Manfred Braun]

Hi All,

I am trying to understand the blocking method socket.Send().
The call blocks as expected, but does this mean, it returnes after the
underlying TCP layer got a confirmation, that the send data was received by
the socket on the remote end? Can I count on that? Do I understand TCP
correctly in that, it gives confirmation [on the underlying level]? I do not
expect, that a .Net based receiver got that data when socket.Send()
terminates!

Hope I was clear,
thanks and best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:_m*************@manfbraun.de
(Remove the anti-spam-underscore to mail me!)

[Arkady Frenkel]

Send() will receive back to you when data will be written to system buffers
of kernel for sending , on receive you'll block untill incoming data will be
written into your buffer
HTH
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:OV**************@tk2msftngp13.phx.gbl...

Hi All,

I am trying to understand the blocking method socket.Send().
The call blocks as expected, but does this mean, it returnes after the
underlying TCP layer got a confirmation, that the send data was received
by
the socket on the remote end? Can I count on that? Do I understand TCP
correctly in that, it gives confirmation [on the underlying level]? I do
not
expect, that a .Net based receiver got that data when socket.Send()
terminates!

Hope I was clear,
thanks and best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:_m*************@manfbraun.de
(Remove the anti-spam-underscore to mail me!)

[Arkady Frenkel]

P.S. So the number of bytes returned ( from Send() ) mean not number of
bytes really send or received on the other side , but number of bytes copied
to system buffer for send, so if that number less than you try to send you
need to resend the last part
Arkady
"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:ex****************@TK2MSFTNGP14.phx.gbl...

Send() will receive back to you when data will be written to system
buffers of kernel for sending , on receive you'll block untill incoming
data will be written into your buffer
HTH
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:OV**************@tk2msftngp13.phx.gbl...

Hi All,

I am trying to understand the blocking method socket.Send().
The call blocks as expected, but does this mean, it returnes after the
underlying TCP layer got a confirmation, that the send data was received
by
the socket on the remote end? Can I count on that? Do I understand TCP
correctly in that, it gives confirmation [on the underlying level]? I do
not
expect, that a .Net based receiver got that data when socket.Send()
terminates!

Hope I was clear,
thanks and best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:_m*************@manfbraun.de
(Remove the anti-spam-underscore to mail me!)

[Manfred Braun]

Hello,

and much thanks first!

Sad! I thought I can count on the delivery garantuee of TCP!! What, if an
error occurs in the underlying layer?? Should I send an explicit
confirmation through my receiver side?? I thought, this is only necessary
with UDP?!

Thanks so far and
best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:u7**************@tk2msftngp13.phx.gbl...

P.S. So the number of bytes returned ( from Send() ) mean not number of
bytes really send or received on the other side , but number of bytes copied to system buffer for send, so if that number less than you try to send you
need to resend the last part
Arkady
"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:ex****************@TK2MSFTNGP14.phx.gbl...

Send() will receive back to you when data will be written to system
buffers of kernel for sending , on receive you'll block untill incoming
data will be written into your buffer
HTH
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:OV**************@tk2msftngp13.phx.gbl...

Hi All,

I am trying to understand the blocking method socket.Send().
The call blocks as expected, but does this mean, it returnes after the
underlying TCP layer got a confirmation, that the send data was received by
the socket on the remote end? Can I count on that? Do I understand TCP
correctly in that, it gives confirmation [on the underlying level]? I do not
expect, that a .Net based receiver got that data when socket.Send()
terminates!

Hope I was clear,
thanks and best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:_m*************@manfbraun.de
(Remove the anti-spam-underscore to mail me!)

[Arkady Frenkel]

Confirmation you do receive, if you after send() you call recv(). You'll
receive error if remote host didn't send ack back to your TCP stack or data
if remote send you something
Arkady
P.S.Delivery raganteed in a sense that TCP stack try few times to resend
data. If no ack return back after all attempts the error code will be
returned

"Manfred Braun" <[e-mail]> wrote in message
news:eH**************@TK2MSFTNGP14.phx.gbl...

Hello,

and much thanks first!

Sad! I thought I can count on the delivery garantuee of TCP!! What, if an
error occurs in the underlying layer?? Should I send an explicit
confirmation through my receiver side?? I thought, this is only necessary
with UDP?!

Thanks so far and
best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:u7**************@tk2msftngp13.phx.gbl...

P.S. So the number of bytes returned ( from Send() ) mean not number of
bytes really send or received on the other side , but number of bytes

copied

to system buffer for send, so if that number less than you try to send
you
need to resend the last part
Arkady
"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:ex****************@TK2MSFTNGP14.phx.gbl...

> Send() will receive back to you when data will be written to system
> buffers of kernel for sending , on receive you'll block untill incoming
> data will be written into your buffer
> HTH
> Arkady
>
> "Manfred Braun" <[e-mail]> wrote in message
> news:OV**************@tk2msftngp13.phx.gbl...
>> Hi All,
>>
>> I am trying to understand the blocking method socket.Send().
>> The call blocks as expected, but does this mean, it returnes after the
>> underlying TCP layer got a confirmation, that the send data was received >> by
>> the socket on the remote end? Can I count on that? Do I understand TCP
>> correctly in that, it gives confirmation [on the underlying level]? I do >> not
>> expect, that a .Net based receiver got that data when socket.Send()
>> terminates!
>>
>> Hope I was clear,
>> thanks and best regards,
>> Manfred Braun
>>
>> (Private)
>> Lange Roetterstrasse 7
>> D68167 Mannheim
>> Germany
>>
>> mailto:_m*************@manfbraun.de
>> (Remove the anti-spam-underscore to mail me!)
>>
>>
>>
>
>

[Manfred Braun]

Hi,

thanks a lot! See "inline" [????]!!!

Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:Or*************@TK2MSFTNGP15.phx.gbl...

Confirmation you do receive, if you after send() you call recv(). You'll
receive error if remote host didn't send ack back to your TCP stack or data if remote send you something
Arkady
P.S.Delivery raganteed in a sense that TCP stack try few times to resend
data. If no ack return back after all attempts the error code will be
returned WHEN DOES THIS HAPPEN ??????????????????????????

"Manfred Braun" <[e-mail]> wrote in message
news:eH**************@TK2MSFTNGP14.phx.gbl...

Hello,

and much thanks first!

Sad! I thought I can count on the delivery garantuee of TCP!! What, if an error occurs in the underlying layer?? Should I send an explicit
confirmation through my receiver side?? I thought, this is only necessary with UDP?!

Thanks so far and
best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:u7**************@tk2msftngp13.phx.gbl...

P.S. So the number of bytes returned ( from Send() ) mean not number of
bytes really send or received on the other side , but number of bytes

copied

to system buffer for send, so if that number less than you try to send
you
need to resend the last part
Arkady
"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:ex****************@TK2MSFTNGP14.phx.gbl...
> Send() will receive back to you when data will be written to system
> buffers of kernel for sending , on receive you'll block untill incoming > data will be written into your buffer
> HTH
> Arkady
>
> "Manfred Braun" <[e-mail]> wrote in message
> news:OV**************@tk2msftngp13.phx.gbl...
>> Hi All,
>>
>> I am trying to understand the blocking method socket.Send().
>> The call blocks as expected, but does this mean, it returnes after the >> underlying TCP layer got a confirmation, that the send data was

received

>> by
>> the socket on the remote end? Can I count on that? Do I understand TCP >> correctly in that, it gives confirmation [on the underlying level]?

I do

>> not
>> expect, that a .Net based receiver got that data when socket.Send()
>> terminates!
>>
>> Hope I was clear,
>> thanks and best regards,
>> Manfred Braun
>>
>> (Private)
>> Lange Roetterstrasse 7
>> D68167 Mannheim
>> Germany
>>
>> mailto:_m*************@manfbraun.de
>> (Remove the anti-spam-underscore to mail me!)
>>
>>
>>
>
>

[Arkady Frenkel]

That depend upon OS you use because registry values depends upon that,
http://support.microsoft.com/?kbid=170359 describe the keys
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:u2**************@TK2MSFTNGP09.phx.gbl...

Hi,

thanks a lot! See "inline" [????]!!!

Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:Or*************@TK2MSFTNGP15.phx.gbl...

Confirmation you do receive, if you after send() you call recv(). You'll
receive error if remote host didn't send ack back to your TCP stack or

data

if remote send you something
Arkady
P.S.Delivery raganteed in a sense that TCP stack try few times to resend
data. If no ack return back after all attempts the error code will be
returned WHEN DOES THIS HAPPEN ??????????????????????????

"Manfred Braun" <[e-mail]> wrote in message
news:eH**************@TK2MSFTNGP14.phx.gbl...

> Hello,
>
> and much thanks first!
>
> Sad! I thought I can count on the delivery garantuee of TCP!! What, if an > error occurs in the underlying layer?? Should I send an explicit
> confirmation through my receiver side?? I thought, this is only necessary > with UDP?!
>
> Thanks so far and
> best regards,
> Manfred
>
> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
> news:u7**************@tk2msftngp13.phx.gbl...
>> P.S. So the number of bytes returned ( from Send() ) mean not number
>> of
>> bytes really send or received on the other side , but number of bytes
> copied
>> to system buffer for send, so if that number less than you try to send
>> you
>> need to resend the last part
>> Arkady
>>
>>
>> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> news:ex****************@TK2MSFTNGP14.phx.gbl...
>> > Send() will receive back to you when data will be written to system
>> > buffers of kernel for sending , on receive you'll block untill incoming >> > data will be written into your buffer
>> > HTH
>> > Arkady
>> >
>> > "Manfred Braun" <[e-mail]> wrote in message
>> > news:OV**************@tk2msftngp13.phx.gbl...
>> >> Hi All,
>> >>
>> >> I am trying to understand the blocking method socket.Send().
>> >> The call blocks as expected, but does this mean, it returnes after the >> >> underlying TCP layer got a confirmation, that the send data was
> received
>> >> by
>> >> the socket on the remote end? Can I count on that? Do I understand TCP >> >> correctly in that, it gives confirmation [on the underlying level]? I > do
>> >> not
>> >> expect, that a .Net based receiver got that data when socket.Send()
>> >> terminates!
>> >>
>> >> Hope I was clear,
>> >> thanks and best regards,
>> >> Manfred Braun
>> >>
>> >> (Private)
>> >> Lange Roetterstrasse 7
>> >> D68167 Mannheim
>> >> Germany
>> >>
>> >> mailto:_m*************@manfbraun.de
>> >> (Remove the anti-spam-underscore to mail me!)
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[Manfred Braun]

Hi,

my summary:

If I send a single packet via TCP, I'll never get an error-message in
"socketSend()", because the error may happen after the retransmission, which
needs some time and "socket.Send()" has returned already [which means the
packet was "scheduled" to the underlying TCP system]. To be absolutely sure,
to have the packet send successfully, my receiver must send an ack!

Am i correct in this?

And thanks a lot for your help!
Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:ue**************@tk2msftngp13.phx.gbl...

That depend upon OS you use because registry values depends upon that,
http://support.microsoft.com/?kbid=170359 describe the keys
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:u2**************@TK2MSFTNGP09.phx.gbl...

Hi,

thanks a lot! See "inline" [????]!!!

Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:Or*************@TK2MSFTNGP15.phx.gbl...

Confirmation you do receive, if you after send() you call recv(). You'll receive error if remote host didn't send ack back to your TCP stack or

data

if remote send you something
Arkady
P.S.Delivery raganteed in a sense that TCP stack try few times to resend data. If no ack return back after all attempts the error code will be
returned WHEN DOES THIS HAPPEN ??????????????????????????

"Manfred Braun" <[e-mail]> wrote in message
news:eH**************@TK2MSFTNGP14.phx.gbl...
> Hello,
>
> and much thanks first!
>
> Sad! I thought I can count on the delivery garantuee of TCP!! What, if

an

> error occurs in the underlying layer?? Should I send an explicit
> confirmation through my receiver side?? I thought, this is only

necessary

> with UDP?!
>
> Thanks so far and
> best regards,
> Manfred
>
> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
> news:u7**************@tk2msftngp13.phx.gbl...
>> P.S. So the number of bytes returned ( from Send() ) mean not number
>> of
>> bytes really send or received on the other side , but number of

bytes > copied
>> to system buffer for send, so if that number less than you try to send >> you
>> need to resend the last part
>> Arkady
>>
>>
>> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> news:ex****************@TK2MSFTNGP14.phx.gbl...
>> > Send() will receive back to you when data will be written to system >> > buffers of kernel for sending , on receive you'll block untill

incoming

>> > data will be written into your buffer
>> > HTH
>> > Arkady
>> >
>> > "Manfred Braun" <[e-mail]> wrote in message
>> > news:OV**************@tk2msftngp13.phx.gbl...
>> >> Hi All,
>> >>
>> >> I am trying to understand the blocking method socket.Send().
>> >> The call blocks as expected, but does this mean, it returnes after the

>> >> underlying TCP layer got a confirmation, that the send data was
> received
>> >> by
>> >> the socket on the remote end? Can I count on that? Do I

understand TCP

>> >> correctly in that, it gives confirmation [on the underlying

level]? I

> do
>> >> not
>> >> expect, that a .Net based receiver got that data when

socket.Send() >> >> terminates!
>> >>
>> >> Hope I was clear,
>> >> thanks and best regards,
>> >> Manfred Braun
>> >>
>> >> (Private)
>> >> Lange Roetterstrasse 7
>> >> D68167 Mannheim
>> >> Germany
>> >>
>> >> mailto:_m*************@manfbraun.de
>> >> (Remove the anti-spam-underscore to mail me!)
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[Arkady Frenkel]

Sorry , didn't saw you last question , but the answer is obviously - Yes.
OTOH you do can receive error still on sending side but that not because of
transmittion error but kernel problems ( like no place too set data and so
forth )
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:eQ**************@tk2msftngp13.phx.gbl...

Hi,

my summary:

If I send a single packet via TCP, I'll never get an error-message in
"socketSend()", because the error may happen after the retransmission,
which
needs some time and "socket.Send()" has returned already [which means the
packet was "scheduled" to the underlying TCP system]. To be absolutely
sure,
to have the packet send successfully, my receiver must send an ack!

Am i correct in this?

And thanks a lot for your help!
Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:ue**************@tk2msftngp13.phx.gbl...

That depend upon OS you use because registry values depends upon that,
http://support.microsoft.com/?kbid=170359 describe the keys
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:u2**************@TK2MSFTNGP09.phx.gbl...

> Hi,
>
> thanks a lot! See "inline" [????]!!!
>
> Best regards,
> Manfred
>
> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
> news:Or*************@TK2MSFTNGP15.phx.gbl...
>> Confirmation you do receive, if you after send() you call recv(). You'll >> receive error if remote host didn't send ack back to your TCP stack or
> data
>> if remote send you something
>> Arkady
>> P.S.Delivery raganteed in a sense that TCP stack try few times to resend >> data. If no ack return back after all attempts the error code will be
>> returned WHEN DOES THIS HAPPEN ??????????????????????????
>>
>> "Manfred Braun" <[e-mail]> wrote in message
>> news:eH**************@TK2MSFTNGP14.phx.gbl...
>> > Hello,
>> >
>> > and much thanks first!
>> >
>> > Sad! I thought I can count on the delivery garantuee of TCP!! What, if > an
>> > error occurs in the underlying layer?? Should I send an explicit
>> > confirmation through my receiver side?? I thought, this is only
> necessary
>> > with UDP?!
>> >
>> > Thanks so far and
>> > best regards,
>> > Manfred
>> >
>> > "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> > news:u7**************@tk2msftngp13.phx.gbl...
>> >> P.S. So the number of bytes returned ( from Send() ) mean not
>> >> number
>> >> of
>> >> bytes really send or received on the other side , but number of bytes >> > copied
>> >> to system buffer for send, so if that number less than you try to send >> >> you
>> >> need to resend the last part
>> >> Arkady
>> >>
>> >>
>> >> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> >> news:ex****************@TK2MSFTNGP14.phx.gbl...
>> >> > Send() will receive back to you when data will be written to system >> >> > buffers of kernel for sending , on receive you'll block untill
> incoming
>> >> > data will be written into your buffer
>> >> > HTH
>> >> > Arkady
>> >> >
>> >> > "Manfred Braun" <[e-mail]> wrote in message
>> >> > news:OV**************@tk2msftngp13.phx.gbl...
>> >> >> Hi All,
>> >> >>
>> >> >> I am trying to understand the blocking method socket.Send().
>> >> >> The call blocks as expected, but does this mean, it returnes after > the
>> >> >> underlying TCP layer got a confirmation, that the send data was
>> > received
>> >> >> by
>> >> >> the socket on the remote end? Can I count on that? Do I understand > TCP
>> >> >> correctly in that, it gives confirmation [on the underlying level]? > I
>> > do
>> >> >> not
>> >> >> expect, that a .Net based receiver got that data when socket.Send() >> >> >> terminates!
>> >> >>
>> >> >> Hope I was clear,
>> >> >> thanks and best regards,
>> >> >> Manfred Braun
>> >> >>
>> >> >> (Private)
>> >> >> Lange Roetterstrasse 7
>> >> >> D68167 Mannheim
>> >> >> Germany
>> >> >>
>> >> >> mailto:_m*************@manfbraun.de
>> >> >> (Remove the anti-spam-underscore to mail me!)
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[Arkady Frenkel]

Sorry , didn't saw you last question , but the answer is obviously - Yes.
OTOH you do can receive error still on sending side but that not because of
transmittion error but kernel problems ( like no place too set data and so
forth )
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:eQ**************@tk2msftngp13.phx.gbl...

Hi,

my summary:

If I send a single packet via TCP, I'll never get an error-message in
"socketSend()", because the error may happen after the retransmission,
which
needs some time and "socket.Send()" has returned already [which means the
packet was "scheduled" to the underlying TCP system]. To be absolutely
sure,
to have the packet send successfully, my receiver must send an ack!

Am i correct in this?

And thanks a lot for your help!
Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:ue**************@tk2msftngp13.phx.gbl...

That depend upon OS you use because registry values depends upon that,
http://support.microsoft.com/?kbid=170359 describe the keys
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:u2**************@TK2MSFTNGP09.phx.gbl...

> Hi,
>
> thanks a lot! See "inline" [????]!!!
>
> Best regards,
> Manfred
>
> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
> news:Or*************@TK2MSFTNGP15.phx.gbl...
>> Confirmation you do receive, if you after send() you call recv(). You'll >> receive error if remote host didn't send ack back to your TCP stack or
> data
>> if remote send you something
>> Arkady
>> P.S.Delivery raganteed in a sense that TCP stack try few times to resend >> data. If no ack return back after all attempts the error code will be
>> returned WHEN DOES THIS HAPPEN ??????????????????????????
>>
>> "Manfred Braun" <[e-mail]> wrote in message
>> news:eH**************@TK2MSFTNGP14.phx.gbl...
>> > Hello,
>> >
>> > and much thanks first!
>> >
>> > Sad! I thought I can count on the delivery garantuee of TCP!! What, if > an
>> > error occurs in the underlying layer?? Should I send an explicit
>> > confirmation through my receiver side?? I thought, this is only
> necessary
>> > with UDP?!
>> >
>> > Thanks so far and
>> > best regards,
>> > Manfred
>> >
>> > "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> > news:u7**************@tk2msftngp13.phx.gbl...
>> >> P.S. So the number of bytes returned ( from Send() ) mean not
>> >> number
>> >> of
>> >> bytes really send or received on the other side , but number of bytes >> > copied
>> >> to system buffer for send, so if that number less than you try to send >> >> you
>> >> need to resend the last part
>> >> Arkady
>> >>
>> >>
>> >> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> >> news:ex****************@TK2MSFTNGP14.phx.gbl...
>> >> > Send() will receive back to you when data will be written to system >> >> > buffers of kernel for sending , on receive you'll block untill
> incoming
>> >> > data will be written into your buffer
>> >> > HTH
>> >> > Arkady
>> >> >
>> >> > "Manfred Braun" <[e-mail]> wrote in message
>> >> > news:OV**************@tk2msftngp13.phx.gbl...
>> >> >> Hi All,
>> >> >>
>> >> >> I am trying to understand the blocking method socket.Send().
>> >> >> The call blocks as expected, but does this mean, it returnes after > the
>> >> >> underlying TCP layer got a confirmation, that the send data was
>> > received
>> >> >> by
>> >> >> the socket on the remote end? Can I count on that? Do I understand > TCP
>> >> >> correctly in that, it gives confirmation [on the underlying level]? > I
>> > do
>> >> >> not
>> >> >> expect, that a .Net based receiver got that data when socket.Send() >> >> >> terminates!
>> >> >>
>> >> >> Hope I was clear,
>> >> >> thanks and best regards,
>> >> >> Manfred Braun
>> >> >>
>> >> >> (Private)
>> >> >> Lange Roetterstrasse 7
>> >> >> D68167 Mannheim
>> >> >> Germany
>> >> >>
>> >> >> mailto:_m*************@manfbraun.de
>> >> >> (Remove the anti-spam-underscore to mail me!)
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[Manfred Braun]

Hello,

tno matter with the delay!! And thanks you a lot for all the help!

Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:eI*************@TK2MSFTNGP15.phx.gbl...

Sorry , didn't saw you last question , but the answer is obviously - Yes.
OTOH you do can receive error still on sending side but that not because of transmittion error but kernel problems ( like no place too set data and so
forth )
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:eQ**************@tk2msftngp13.phx.gbl...

Hi,

my summary:

If I send a single packet via TCP, I'll never get an error-message in
"socketSend()", because the error may happen after the retransmission,
which
needs some time and "socket.Send()" has returned already [which means the packet was "scheduled" to the underlying TCP system]. To be absolutely
sure,
to have the packet send successfully, my receiver must send an ack!

Am i correct in this?

And thanks a lot for your help!
Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:ue**************@tk2msftngp13.phx.gbl...

That depend upon OS you use because registry values depends upon that,
http://support.microsoft.com/?kbid=170359 describe the keys
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:u2**************@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> thanks a lot! See "inline" [????]!!!
>
> Best regards,
> Manfred
>
> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
> news:Or*************@TK2MSFTNGP15.phx.gbl...
>> Confirmation you do receive, if you after send() you call recv().

You'll

>> receive error if remote host didn't send ack back to your TCP stack or > data
>> if remote send you something
>> Arkady
>> P.S.Delivery raganteed in a sense that TCP stack try few times to

resend

>> data. If no ack return back after all attempts the error code will be >> returned WHEN DOES THIS HAPPEN ??????????????????????????
>>
>> "Manfred Braun" <[e-mail]> wrote in message
>> news:eH**************@TK2MSFTNGP14.phx.gbl...
>> > Hello,
>> >
>> > and much thanks first!
>> >
>> > Sad! I thought I can count on the delivery garantuee of TCP!! What,

if

> an
>> > error occurs in the underlying layer?? Should I send an explicit
>> > confirmation through my receiver side?? I thought, this is only
> necessary
>> > with UDP?!
>> >
>> > Thanks so far and
>> > best regards,
>> > Manfred
>> >
>> > "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> > news:u7**************@tk2msftngp13.phx.gbl...
>> >> P.S. So the number of bytes returned ( from Send() ) mean not
>> >> number
>> >> of
>> >> bytes really send or received on the other side , but number of

bytes

>> > copied
>> >> to system buffer for send, so if that number less than you try to

send

>> >> you
>> >> need to resend the last part
>> >> Arkady
>> >>
>> >>
>> >> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> >> news:ex****************@TK2MSFTNGP14.phx.gbl...
>> >> > Send() will receive back to you when data will be written to

system

>> >> > buffers of kernel for sending , on receive you'll block untill
> incoming
>> >> > data will be written into your buffer
>> >> > HTH
>> >> > Arkady
>> >> >
>> >> > "Manfred Braun" <[e-mail]> wrote in message
>> >> > news:OV**************@tk2msftngp13.phx.gbl...
>> >> >> Hi All,
>> >> >>
>> >> >> I am trying to understand the blocking method socket.Send().
>> >> >> The call blocks as expected, but does this mean, it returnes

after

> the
>> >> >> underlying TCP layer got a confirmation, that the send data

was >> > received
>> >> >> by
>> >> >> the socket on the remote end? Can I count on that? Do I

understand

> TCP
>> >> >> correctly in that, it gives confirmation [on the underlying

level]?

> I
>> > do
>> >> >> not
>> >> >> expect, that a .Net based receiver got that data when

socket.Send()

>> >> >> terminates!
>> >> >>
>> >> >> Hope I was clear,
>> >> >> thanks and best regards,
>> >> >> Manfred Braun
>> >> >>
>> >> >> (Private)
>> >> >> Lange Roetterstrasse 7
>> >> >> D68167 Mannheim
>> >> >> Germany
>> >> >>
>> >> >> mailto:_m*************@manfbraun.de
>> >> >> (Remove the anti-spam-underscore to mail me!)
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[Manfred Braun]

Hello,

tno matter with the delay!! And thanks you a lot for all the help!

Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:eI*************@TK2MSFTNGP15.phx.gbl...

Sorry , didn't saw you last question , but the answer is obviously - Yes.
OTOH you do can receive error still on sending side but that not because of transmittion error but kernel problems ( like no place too set data and so
forth )
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:eQ**************@tk2msftngp13.phx.gbl...

Hi,

my summary:

If I send a single packet via TCP, I'll never get an error-message in
"socketSend()", because the error may happen after the retransmission,
which
needs some time and "socket.Send()" has returned already [which means the packet was "scheduled" to the underlying TCP system]. To be absolutely
sure,
to have the packet send successfully, my receiver must send an ack!

Am i correct in this?

And thanks a lot for your help!
Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:ue**************@tk2msftngp13.phx.gbl...

That depend upon OS you use because registry values depends upon that,
http://support.microsoft.com/?kbid=170359 describe the keys
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:u2**************@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> thanks a lot! See "inline" [????]!!!
>
> Best regards,
> Manfred
>
> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
> news:Or*************@TK2MSFTNGP15.phx.gbl...
>> Confirmation you do receive, if you after send() you call recv().

You'll

>> receive error if remote host didn't send ack back to your TCP stack or > data
>> if remote send you something
>> Arkady
>> P.S.Delivery raganteed in a sense that TCP stack try few times to

resend

>> data. If no ack return back after all attempts the error code will be >> returned WHEN DOES THIS HAPPEN ??????????????????????????
>>
>> "Manfred Braun" <[e-mail]> wrote in message
>> news:eH**************@TK2MSFTNGP14.phx.gbl...
>> > Hello,
>> >
>> > and much thanks first!
>> >
>> > Sad! I thought I can count on the delivery garantuee of TCP!! What,

if

> an
>> > error occurs in the underlying layer?? Should I send an explicit
>> > confirmation through my receiver side?? I thought, this is only
> necessary
>> > with UDP?!
>> >
>> > Thanks so far and
>> > best regards,
>> > Manfred
>> >
>> > "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> > news:u7**************@tk2msftngp13.phx.gbl...
>> >> P.S. So the number of bytes returned ( from Send() ) mean not
>> >> number
>> >> of
>> >> bytes really send or received on the other side , but number of

bytes

>> > copied
>> >> to system buffer for send, so if that number less than you try to

send

>> >> you
>> >> need to resend the last part
>> >> Arkady
>> >>
>> >>
>> >> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> >> news:ex****************@TK2MSFTNGP14.phx.gbl...
>> >> > Send() will receive back to you when data will be written to

system

>> >> > buffers of kernel for sending , on receive you'll block untill
> incoming
>> >> > data will be written into your buffer
>> >> > HTH
>> >> > Arkady
>> >> >
>> >> > "Manfred Braun" <[e-mail]> wrote in message
>> >> > news:OV**************@tk2msftngp13.phx.gbl...
>> >> >> Hi All,
>> >> >>
>> >> >> I am trying to understand the blocking method socket.Send().
>> >> >> The call blocks as expected, but does this mean, it returnes

after

> the
>> >> >> underlying TCP layer got a confirmation, that the send data

was >> > received
>> >> >> by
>> >> >> the socket on the remote end? Can I count on that? Do I

understand

> TCP
>> >> >> correctly in that, it gives confirmation [on the underlying

level]?

> I
>> > do
>> >> >> not
>> >> >> expect, that a .Net based receiver got that data when

socket.Send()

>> >> >> terminates!
>> >> >>
>> >> >> Hope I was clear,
>> >> >> thanks and best regards,
>> >> >> Manfred Braun
>> >> >>
>> >> >> (Private)
>> >> >> Lange Roetterstrasse 7
>> >> >> D68167 Mannheim
>> >> >> Germany
>> >> >>
>> >> >> mailto:_m*************@manfbraun.de
>> >> >> (Remove the anti-spam-underscore to mail me!)
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[Alun Jones [MSFT]]

Just a further statement on this - you don't want to know whether the TCP
stack at the other end has received your data - you want to know whether the
_application_ at the other end has received your data. Data sitting in the
remote TCP stack, but not yet processed by the remote application, is as
unprocessed as data in the network cloud, or in your NIC's buffers waiting
to be sent, or in your own TCP stack's buffers waiting to be sent.

You want to know when the application at the remote peer has received and
processed the data - the only party that can tell you that is the remote
application. If you care that the remote application has received and
processed the data (even if that "processing" is as simple as reading the
data off the network stack and into local memory), you can _only_ get that
information by having the remote application send you a message that
indicates this success.

Alun.
~~~~
--
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights.
"Manfred Braun" <[e-mail]> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

Hello,

tno matter with the delay!! And thanks you a lot for all the help!

Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:eI*************@TK2MSFTNGP15.phx.gbl...

Sorry , didn't saw you last question , but the answer is obviously - Yes.
OTOH you do can receive error still on sending side but that not because

of

transmittion error but kernel problems ( like no place too set data and
so
forth )
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:eQ**************@tk2msftngp13.phx.gbl...

> Hi,
>
> my summary:
>
> If I send a single packet via TCP, I'll never get an error-message in
> "socketSend()", because the error may happen after the retransmission,
> which
> needs some time and "socket.Send()" has returned already [which means the > packet was "scheduled" to the underlying TCP system]. To be absolutely
> sure,
> to have the packet send successfully, my receiver must send an ack!
>
> Am i correct in this?
>
> And thanks a lot for your help!
> Best regards,
> Manfred
>
> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
> news:ue**************@tk2msftngp13.phx.gbl...
>> That depend upon OS you use because registry values depends upon that,
>> http://support.microsoft.com/?kbid=170359 describe the keys
>> Arkady
>>
>> "Manfred Braun" <[e-mail]> wrote in message
>> news:u2**************@TK2MSFTNGP09.phx.gbl...
>> > Hi,
>> >
>> > thanks a lot! See "inline" [????]!!!
>> >
>> > Best regards,
>> > Manfred
>> >
>> > "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> > news:Or*************@TK2MSFTNGP15.phx.gbl...
>> >> Confirmation you do receive, if you after send() you call recv().
> You'll
>> >> receive error if remote host didn't send ack back to your TCP stack or >> > data
>> >> if remote send you something
>> >> Arkady
>> >> P.S.Delivery raganteed in a sense that TCP stack try few times to
> resend
>> >> data. If no ack return back after all attempts the error code will be >> >> returned WHEN DOES THIS HAPPEN ??????????????????????????
>> >>
>> >> "Manfred Braun" <[e-mail]> wrote in message
>> >> news:eH**************@TK2MSFTNGP14.phx.gbl...
>> >> > Hello,
>> >> >
>> >> > and much thanks first!
>> >> >
>> >> > Sad! I thought I can count on the delivery garantuee of TCP!! What, > if
>> > an
>> >> > error occurs in the underlying layer?? Should I send an explicit
>> >> > confirmation through my receiver side?? I thought, this is only
>> > necessary
>> >> > with UDP?!
>> >> >
>> >> > Thanks so far and
>> >> > best regards,
>> >> > Manfred
>> >> >
>> >> > "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> >> > news:u7**************@tk2msftngp13.phx.gbl...
>> >> >> P.S. So the number of bytes returned ( from Send() ) mean not
>> >> >> number
>> >> >> of
>> >> >> bytes really send or received on the other side , but number of
> bytes
>> >> > copied
>> >> >> to system buffer for send, so if that number less than you try
>> >> >> to
> send
>> >> >> you
>> >> >> need to resend the last part
>> >> >> Arkady
>> >> >>
>> >> >>
>> >> >> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> >> >> news:ex****************@TK2MSFTNGP14.phx.gbl...
>> >> >> > Send() will receive back to you when data will be written to
> system
>> >> >> > buffers of kernel for sending , on receive you'll block untill
>> > incoming
>> >> >> > data will be written into your buffer
>> >> >> > HTH
>> >> >> > Arkady
>> >> >> >
>> >> >> > "Manfred Braun" <[e-mail]> wrote in message
>> >> >> > news:OV**************@tk2msftngp13.phx.gbl...
>> >> >> >> Hi All,
>> >> >> >>
>> >> >> >> I am trying to understand the blocking method socket.Send().
>> >> >> >> The call blocks as expected, but does this mean, it returnes
> after
>> > the
>> >> >> >> underlying TCP layer got a confirmation, that the send data was >> >> > received
>> >> >> >> by
>> >> >> >> the socket on the remote end? Can I count on that? Do I
> understand
>> > TCP
>> >> >> >> correctly in that, it gives confirmation [on the underlying
> level]?
>> > I
>> >> > do
>> >> >> >> not
>> >> >> >> expect, that a .Net based receiver got that data when
> socket.Send()
>> >> >> >> terminates!
>> >> >> >>
>> >> >> >> Hope I was clear,
>> >> >> >> thanks and best regards,
>> >> >> >> Manfred Braun
>> >> >> >>
>> >> >> >> (Private)
>> >> >> >> Lange Roetterstrasse 7
>> >> >> >> D68167 Mannheim
>> >> >> >> Germany
>> >> >> >>
>> >> >> >> mailto:_m*************@manfbraun.de
>> >> >> >> (Remove the anti-spam-underscore to mail me!)
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[Manfred Braun]

Hi,

and really much thanks a lot!!! So I simply misunderstood the TCP stack!
Sorry for my delay, I've not exptected more answers, but this one is great!

Best regards,
Manfred

"Alun Jones [MSFT]" <al***@online.microsoft.com> wrote in message
news:uB**************@TK2MSFTNGP10.phx.gbl...

Just a further statement on this - you don't want to know whether the TCP
stack at the other end has received your data - you want to know whether the _application_ at the other end has received your data. Data sitting in the remote TCP stack, but not yet processed by the remote application, is as
unprocessed as data in the network cloud, or in your NIC's buffers waiting
to be sent, or in your own TCP stack's buffers waiting to be sent.

You want to know when the application at the remote peer has received and
processed the data - the only party that can tell you that is the remote
application. If you care that the remote application has received and
processed the data (even if that "processing" is as simple as reading the
data off the network stack and into local memory), you can _only_ get that
information by having the remote application send you a message that
indicates this success.

Alun.
~~~~
--
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights. "Manfred Braun" <[e-mail]> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

Hello,

tno matter with the delay!! And thanks you a lot for all the help!

Best regards,
Manfred

"Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
news:eI*************@TK2MSFTNGP15.phx.gbl...

Sorry , didn't saw you last question , but the answer is obviously - Yes. OTOH you do can receive error still on sending side but that not because

of

transmittion error but kernel problems ( like no place too set data and
so
forth )
Arkady

"Manfred Braun" <[e-mail]> wrote in message
news:eQ**************@tk2msftngp13.phx.gbl...
> Hi,
>
> my summary:
>
> If I send a single packet via TCP, I'll never get an error-message in
> "socketSend()", because the error may happen after the

retransmission, > which
> needs some time and "socket.Send()" has returned already [which means

the

> packet was "scheduled" to the underlying TCP system]. To be absolutely > sure,
> to have the packet send successfully, my receiver must send an ack!
>
> Am i correct in this?
>
> And thanks a lot for your help!
> Best regards,
> Manfred
>
> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
> news:ue**************@tk2msftngp13.phx.gbl...
>> That depend upon OS you use because registry values depends upon that, >> http://support.microsoft.com/?kbid=170359 describe the keys
>> Arkady
>>
>> "Manfred Braun" <[e-mail]> wrote in message
>> news:u2**************@TK2MSFTNGP09.phx.gbl...
>> > Hi,
>> >
>> > thanks a lot! See "inline" [????]!!!
>> >
>> > Best regards,
>> > Manfred
>> >
>> > "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> > news:Or*************@TK2MSFTNGP15.phx.gbl...
>> >> Confirmation you do receive, if you after send() you call recv().
> You'll
>> >> receive error if remote host didn't send ack back to your TCP stack or

>> > data
>> >> if remote send you something
>> >> Arkady
>> >> P.S.Delivery raganteed in a sense that TCP stack try few times to
> resend
>> >> data. If no ack return back after all attempts the error code

will be

>> >> returned WHEN DOES THIS HAPPEN ??????????????????????????
>> >>
>> >> "Manfred Braun" <[e-mail]> wrote in message
>> >> news:eH**************@TK2MSFTNGP14.phx.gbl...
>> >> > Hello,
>> >> >
>> >> > and much thanks first!
>> >> >
>> >> > Sad! I thought I can count on the delivery garantuee of TCP!!

What,

> if
>> > an
>> >> > error occurs in the underlying layer?? Should I send an

explicit >> >> > confirmation through my receiver side?? I thought, this is only
>> > necessary
>> >> > with UDP?!
>> >> >
>> >> > Thanks so far and
>> >> > best regards,
>> >> > Manfred
>> >> >
>> >> > "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> >> > news:u7**************@tk2msftngp13.phx.gbl...
>> >> >> P.S. So the number of bytes returned ( from Send() ) mean not
>> >> >> number
>> >> >> of
>> >> >> bytes really send or received on the other side , but number of > bytes
>> >> > copied
>> >> >> to system buffer for send, so if that number less than you try
>> >> >> to
> send
>> >> >> you
>> >> >> need to resend the last part
>> >> >> Arkady
>> >> >>
>> >> >>
>> >> >> "Arkady Frenkel" <ar*****@hotmailxdotx.com> wrote in message
>> >> >> news:ex****************@TK2MSFTNGP14.phx.gbl...
>> >> >> > Send() will receive back to you when data will be written to
> system
>> >> >> > buffers of kernel for sending , on receive you'll block untill >> > incoming
>> >> >> > data will be written into your buffer
>> >> >> > HTH
>> >> >> > Arkady
>> >> >> >
>> >> >> > "Manfred Braun" <[e-mail]> wrote in message
>> >> >> > news:OV**************@tk2msftngp13.phx.gbl...
>> >> >> >> Hi All,
>> >> >> >>
>> >> >> >> I am trying to understand the blocking method socket.Send(). >> >> >> >> The call blocks as expected, but does this mean, it returnes > after
>> > the
>> >> >> >> underlying TCP layer got a confirmation, that the send data

was

>> >> > received
>> >> >> >> by
>> >> >> >> the socket on the remote end? Can I count on that? Do I
> understand
>> > TCP
>> >> >> >> correctly in that, it gives confirmation [on the underlying
> level]?
>> > I
>> >> > do
>> >> >> >> not
>> >> >> >> expect, that a .Net based receiver got that data when
> socket.Send()
>> >> >> >> terminates!
>> >> >> >>
>> >> >> >> Hope I was clear,
>> >> >> >> thanks and best regards,
>> >> >> >> Manfred Braun
>> >> >> >>
>> >> >> >> (Private)
>> >> >> >> Lange Roetterstrasse 7
>> >> >> >> D68167 Mannheim
>> >> >> >> Germany
>> >> >> >>
>> >> >> >> mailto:_m*************@manfbraun.de
>> >> >> >> (Remove the anti-spam-underscore to mail me!)
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>