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:[email protected]
(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

 

[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

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

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:[email protected]
(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

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

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

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:[email protected]
(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

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

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

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

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:[email protected]
(Remove the anti-spam-underscore to mail me!)

 

[Manfred Braun]

Hi,

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

Best regards,
Manfred

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 ??????????????????????????

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

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


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

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:[email protected]
(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

Hi,

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

Best regards,
Manfred

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 ??????????????????????????

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

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


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

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:[email protected]
(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

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

Hi,

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

Best regards,
Manfred

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 ??????????????????????????

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

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


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

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:[email protected]
(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

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

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

Hi,

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

Best regards,
Manfred

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 ??????????????????????????

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

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


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

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:[email protected]
(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

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

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

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

Hi,

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

Best regards,
Manfred

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 ??????????????????????????

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

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


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

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:[email protected]
(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

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.

Hello,

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

Best regards,
Manfred

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

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

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

Hi,

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

Best regards,
Manfred

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 ??????????????????????????

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

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


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

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:[email protected]
(Remove the anti-spam-underscore to mail me!)