Re: TCP Blocking sockets

From: Nicolai Hansen (nic_at_aub.dk)
Date: 02/16/04 

Date: 16 Feb 2004 01:23:29 -0800

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

Relevant Pages

  • Re: TCP Blocking sockets
    ... the tcp buffers don't fill up etc due to slow link speeds. ... With TCP/IP the receiving system will wait for the packet to ... >arrives, ... UDP doesn't ensure you data delivery, ...
    (alt.comp.lang.borland-delphi)
  • alt.2600 FAQ Revision .014 (2/4)
    ... One type of firewall is the packet filtering firewall. ... Dropping packets instead of rejecting them greatly increases the time required to scan your network. ... Port scanning UDP ports is much slower than port scanning TCP ports. ... Chartreuse Use the electricity from your phone line Cheese Connect two phones to create a diverter Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • Re: jailed "system" needs IPV4 access
    ... see if the ACK flag is set on a tcp packet. ... the keep-state option just ... 00500 deny log ip from 192.160.1.0/24 to any in via dc1 ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Incoherent E-mails
    ... The Novell crap was originally run on IPX ... The term in the early-mid nineties was "packet storm". ... The original advantage of UDP was ... > 60 bytes for TCP. ...
    (alt.computer.security)
  • Re: A question regarding MTU: how it can effect TCP performance + other queries
    ... Can you check if your physical NIC has TCP large send offload enabled? ... I can't think of anything for the UDP case however, that just seems strange to me. ... Are you grouping multiple UDP packets in one TCP packet? ... encapsulated within another TCP packet when passed to physical interface, while for UDP I am sending UDP packet encapsulated within TCP packet when passed to physical interface. ...
    (microsoft.public.development.device.drivers)