469,629 Members | 1,254 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,629 developers. It's quick & easy.

Understanding socket.Send() with TCP and confirmation

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!)

Nov 17 '05 #1
13 7663
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" <aa@bb.cc> 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!)

Nov 17 '05 #2
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" <aa@bb.cc> 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!)


Nov 17 '05 #3
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" <aa@bb.cc> 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!)



Nov 17 '05 #4
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" <aa@bb.cc> 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" <aa@bb.cc> 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!)
>>
>>
>>
>
>



Nov 17 '05 #5
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" <aa@bb.cc> 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" <aa@bb.cc> 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!)
>>
>>
>>
>
>



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

"Manfred Braun" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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!)
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Nov 17 '05 #7
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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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!)
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Nov 17 '05 #8
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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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!)
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Nov 17 '05 #9
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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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!)
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Nov 17 '05 #10
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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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!)
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Nov 17 '05 #11
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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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!)
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Nov 17 '05 #12
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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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!)
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Nov 17 '05 #13
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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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" <aa@bb.cc> 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!)
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Nov 17 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Anders Both | last post: by
2 posts views Thread by Nuno Magalhaes | last post: by
6 posts views Thread by Abubakar | last post: by
11 posts views Thread by hazz | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.