RE: TCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jeyasekar,
The way to maximize flowrate through a pipe is to attain, at steady
state, a pipe filled with moving data. For a TCP connection, this is
accomplished by allowing the source node to send a data packet to the
destination node before getting an ACK packet acknowledgement from the
destination for the previous data packet. Using the vaguely-named
"window size" field in the TCP Header, the destination tells the source
the size of a Recv_Buffer that awaits an uninterrupted flow of data. (By
the way, the source does eventually get the ACK packets.) 
Analogous to a water pipe's volume equalling x-sectional area * length,
the data formula is (see W.R.Stevens' TCP/IP Illustrated, Vol.1,
Chap.20): 
	iRecv_Buffer_in_Bytes = iBandWidth_of_Pipe_in_Bytes_per_Sec *
iRound_Trip_Time_in_Sec

Once the calculation is made, I use Microsoft WinSock2's "setsockopt(
a_SOCKET, SOL_SOCKET, SO_RCVBUF, ( char*) & iRecv_Buffer_in_Bytes,
sizeof( long))" to initialize the socket.
I throw in "setsockopt( a_SOCKET, SOL_SOCKET, SO_SNDBUF, ( char*) &
iRecv_Buffer_in_Bytes, sizeof( long))" for the Send_Buffer, but I don't
know what that is or does :-(.

Although the flowrates are as expected, my TCP connections are prone to
silent breakage. Since my data transmission must be error-free, some
complex code is needed to remake connections and to resend missing data.
I'm contemplating an alternate (and simpler) design: Divide a file (ie:
the data) into chunks (1460 Bytes for Ethernet convenience?), attach a
ChunkID to each chunk to enable re-assembly at the destination, and send
them off on a **UDP** connection. Only one low-flow TCP connection would
be necessary for supervisory duties such as requesting resends of
missing chunks. Time for some R&D.
	Trace Bond
	Vancouver

PS0: TCP/IP's and UDP/IP's transmission error checking (the "16-bit
checksum" field in the TCP/UDP Header) is quite primitive and has been
badly fooled on my watch. I recommend that the source attach to the data
some dependable CRC value that the destination can use to confirm
error-free transmission.
PS1: Latency is a component in the iRound_Trip_Time_in_Sec.

________________________________

From: Jeyasekar Antony [mailto:antonyjeyasekar@xxxxxxxxx] 
Sent: Saturday, 15 December, 2007 02:18
To: ietf@xxxxxxxx
Subject: TCP

hi
I heard that TCP is not suitable for high speed network because of its
instability, lattency. 
 
is it true? is there any research work going on in this context? 
 
jeyasekar

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]