Re: TCP Blocking sockets
From: Dennis Edward (nospam_at_nowaynohow.org)
Date: Mon, 16 Feb 2004 16:21:37 GMT
Actually, a blocking socket does *not* block until the other side receives
it. A blocking socket blocks until the submitted data is successfully queued
in the stack for sending. Transmission can still fail if the network goes
down after the blocking call returns and before the data is sent. TCP
guaranteed delivery says that as long as the network is functioning, that
data *will* arrive, and *will* be presented to the receiver in proper order.
As to the question about in-transit data, you can set up a
positive-acknowledgement system of some kind between sender and receiver.
"Nicolai Hansen" <email@example.com> wrote in message
> > I guess if I don't want to flood a tcp link with data, I'm going to have
> > tuver end to tell me it's rx'ed byte count/syn type value (or such
like) - ie,
> > do another layer of handshaking over the tcp link.
> The TCP protocol ensures delivery. The TCP protocol has checksums to
> ensure correct data transfer, and will raise errors when incorrect
> data arrives.
> There is no handshaking needed when you are using TCP.
> > Either that, or just limit the amount of data sent per second say - but
> > thru-put can vary at times (especially on GPRS), it's not an accurate
> > how much data is in transit.
> How much data are you going to send here? It sounds like you are going
> to send a whole lot :)
> > The number of bytes that's in transit is what I'm really after, or
> > much of what I've sent has been rx'ed at other end - to be able to judge
> > fast I can push the data into the socket without flooding the thing.
> AFAIK this is not something you can get from standard TCP. You'll have
> to move it to the application layer and send some data back.
> Also, for your original question about blocking vs non-blocking
> The most important difference here is that Delphi generates socket
> events when using non-blocking (asynchronus) sockets. If you use
> blocking sockets, you often also want to run their read/write in a
> thread, as the synchronous read/write blocks execution of the rest of
> your code (if this is what you want, do NOT use threads of course). A
> blocking Read can be quite deadly if there is no data incoming :)
> And another thing: Usually when sending large amounts of data it is
> due to sending the same parameters over and over again. In this case
> it is very important to consider the situation of a lost/delayed
> packet. With TCP/IP the receiving system will wait for the packet to
> arrive. Later packets might arrive, but will stay in the buffer (no
> read event) until the missing packet is there. And when the packet
> arrives, its data is already out-dated. In such situations UDP is a
> much better protocol to use. UDP doesn't ensure you data delivery, and
> certainly not delivery on-time! But because of this packets arriving
> late doesn't clough up the system - they just arrive later. If you put
> a unique counter into each packet it is easy for the receiving end to
> drop out-dated packets and you got something a little less reliable,
> but much smoother running, than the TCP solution.