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