Re: TCP Blocking sockets
no_email_addy_at_no_email_addy.com
Date: 02/16/04
- Next message: no_email_addy_at_no_email_addy.com: "Re: TCP Blocking sockets"
- Previous message: Skybuck Flying: "Re: test"
- In reply to: Nicolai Hansen: "Re: TCP Blocking sockets"
- Next in thread: Dennis Edward: "Re: TCP Blocking sockets"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 16 Feb 2004 11:55:08 GMT
>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.
Aye I know that, but I'm streaming live data (GPS etc) so I need to make sure
the tcp buffers don't fill up etc due to slow link speeds.
>> 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 :)
It varies, but yes it can be a couple of MBytes (not a lot by todays standards),
which is a lot when it comes to GPRS, and as GPRS can be unreliable, I just
wanted to make sure all the streamed data isn't building up to much in the
buffers.
>> 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.
Yeah, was just wondering whether blocking mode in delphi tcp sockets was waiting
till the data had actually been rx'ed at other end or not - as that's not the
case, I'll just have to get the other end to tell me when it rx'ed the data (but
add's to costs).
>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 :)
Yep, I'm ok with threads etc.
>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.
I was thinking about using UDP, but as the data is real time stuff and needs to
be in proper sequence, I thought I'd try tcp first. I can drop some data if the
link can't cope with the amount of data being sent. The trouble is, the other
end is not a pc, it only has around 256 bytes of ram for buffering data, so
buffering and sorting out of sequence UDP data is a problem.
As it's for use on GPRS (low data rate and unpredictable data rate), I didunt
want to end up paying for lost UDP packet data (you pay for the amount of data
transferred), as I don't yet know if you still have to pay for lost UDP packets,
so I went the TCP route.
It may turn out that UDP may be better suited, time and testing will tell.
Clive
- Next message: no_email_addy_at_no_email_addy.com: "Re: TCP Blocking sockets"
- Previous message: Skybuck Flying: "Re: test"
- In reply to: Nicolai Hansen: "Re: TCP Blocking sockets"
- Next in thread: Dennis Edward: "Re: TCP Blocking sockets"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
