Home > Archive > Unix Programming > January 2005 > regarding tcp issue
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
regarding tcp issue
|
|
|
| Hi,
my comments are below u'r points.my browser is showing some problem if
I click follow-up to this messege.
If your application at point 'a' wants to be sure that application at
point 'b' has received the data, then your application at point 'b'
should send some acknowledgment. See for example HTTP protocol.
->Can u tell me in particular that can we extract header part of tcp
sengment we send?
TCP does reliable transmission. It just means that the packet that you
put into systems outgoing buffer will be delievered to the systems
incoming buffer of the peer (provided that network didn't go down).
But
if the application on the other side stopped reading from the systems
incoming buffers, then of course it won't receive the data. This is
the
first reason why explicit acknowledgment from remote application is
good.
-> So u mean to say that if one is using TCP for transmission and
(application level) not kept any provition for explicit
acknowledgement from the other end appliaction for each of his
packet/segment, then there is no way that sender
confirms at the application level that his data is delivered.
Going back to TCP. If the network link (physical) was lost, then TCP
will try to resend your data untill certain timer expires. This timer
is
pretty long. If the link comes back, then the data will be delivered,
otherwise your socket will get an error (this should be visible in
poll/select). Most of the time such long delays are not acceptable, so
explicit acknowledgment again can help in this situation.
-> The main reason I posted this msg is I am writing a program(using
tcp) to find the round trip time of packets. so what I am thinking is
instead of maintaining explicit sequence num ack number of packets and
echoing the packets back and then find the timings, why I shouldn't do
like this?
simply send packets on tcp and now if u r able to extract the tcp
headers of packets u get a ready information of sequence number, ack
number. so directly using these and finding out the timings I can
check rtt.since since timings is critical part here, sending sequence
number along packet explicitly from the application level and getting
its response from the other end application and then getting its rtt,
i feel it becomes an overhead and time consuming and may lead to wrong
rtt values..
so I want to know what I am thinking is right or wrong?
One more point. With networks usually one can not be sure which
program
listens on the other side. Receiving of appropriate acknoledgments
definetely help :)
Of course if none of the above makes concerns, then you can simply
rely
on the fact that TCP will either transfer your data to the peer, or
will
report an error. Read more on that in man 7 tcp man 7 socket.
->I have gone through this man page but still i haven't got
satisfactory information.
kanti
| |
| Barry Margolin 2005-01-16, 3:58 am |
| In article <89f9d3cd.0501142132.4d3bbb0b@posting.google.com>,
kanti_14@rediffmail.com (Kanti) wrote:
> Hi,
> my comments are below u'r points.my browser is showing some problem if
> I click follow-up to this messege.
Use a real news server and newsreader application instead of Google.
Why do people continue to use that sucky news interface?
> If your application at point 'a' wants to be sure that application at
> point 'b' has received the data, then your application at point 'b'
> should send some acknowledgment. See for example HTTP protocol.
>
>
> ->Can u tell me in particular that can we extract header part of tcp
> sengment we send?
The application can't get at the TCP header. What he was saying is that
you should implement an acknowledgement mechanism in your application
protocol. For instance, look at the response codes in SMTP, FTP, and
HTTP.
> TCP does reliable transmission. It just means that the packet that you
> put into systems outgoing buffer will be delievered to the systems
> incoming buffer of the peer (provided that network didn't go down).
> But
> if the application on the other side stopped reading from the systems
> incoming buffers, then of course it won't receive the data. This is
> the
> first reason why explicit acknowledgment from remote application is
> good.
>
>
> -> So u mean to say that if one is using TCP for transmission and
> (application level) not kept any provition for explicit
> acknowledgement from the other end appliaction for each of his
> packet/segment, then there is no way that sender
> confirms at the application level that his data is delivered.
Correct. If there's a failure that prevents your transmissions from
getting through, you'll eventually get an error due to the
retransmission limit being reached. But you don't have access to
detailed status information.
> Going back to TCP. If the network link (physical) was lost, then TCP
> will try to resend your data untill certain timer expires. This timer
> is
> pretty long. If the link comes back, then the data will be delivered,
> otherwise your socket will get an error (this should be visible in
> poll/select). Most of the time such long delays are not acceptable, so
> explicit acknowledgment again can help in this situation.
>
> -> The main reason I posted this msg is I am writing a program(using
> tcp) to find the round trip time of packets. so what I am thinking is
> instead of maintaining explicit sequence num ack number of packets and
> echoing the packets back and then find the timings, why I shouldn't do
> like this?
>
> simply send packets on tcp and now if u r able to extract the tcp
> headers of packets u get a ready information of sequence number, ack
> number. so directly using these and finding out the timings I can
> check rtt.since since timings is critical part here, sending sequence
> number along packet explicitly from the application level and getting
> its response from the other end application and then getting its rtt,
> i feel it becomes an overhead and time consuming and may lead to wrong
> rtt values..
> so I want to know what I am thinking is right or wrong?
If you want to measure RTT with the least overhead, use ping. However,
sending TCP packets containing sequence numbers, and having the
application acknowledge them is a good way of approximating RTT in
typical applications. Real applications have to send and read data like
this, so this test would be the most realistic.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
|
|
|
|
|