Re: TCP Blocking sockets
From: Dennis Edward (nospam_at_nowaynohow.org)
Date: 02/16/04
- Next message: Dragon Lord: "Re: How to disable <CTRL> key??"
- Previous message: Christakis John: "Recommended Delphi 7 books"
- In reply to: Nicolai Hansen: "Re: TCP Blocking sockets"
- Next in thread: Dragon Lord: "Re: TCP Blocking sockets"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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" <nic@aub.dk> wrote in message
news:d96764ff.0402160123.18561731@posting.google.com...
> > I guess if I don't want to flood a tcp link with data, I'm going to have
to get
> > 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
as
> > thru-put can vary at times (especially on GPRS), it's not an accurate
measure of
> > 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
rather how
> > much of what I've sent has been rx'ed at other end - to be able to judge
how
> > 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
> sockets:
> 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.
- Next message: Dragon Lord: "Re: How to disable <CTRL> key??"
- Previous message: Christakis John: "Recommended Delphi 7 books"
- In reply to: Nicolai Hansen: "Re: TCP Blocking sockets"
- Next in thread: Dragon Lord: "Re: TCP Blocking sockets"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|