Full Disclosure mailing list archives
Re: TCP / IP
From: Honza Vlach <janus () volny cz>
Date: Sun, 17 Oct 2004 11:12:39 +0200
Hi, actually, the window says how much the other host can accept due to e.g. link congestion, disk activity etc. There is no point in sending more data than the destination can handle, because it would ack the part of it and everything after the error must be retransmitted. So in your example, if host sees that segment 3 is missing, it's pointles if it has 4,5 and 7. Retransmissions would go from segment 3. HTH, Honza On Sat, Oct 16, 2004 at 04:49:52PM -0700, D B wrote:
From: D B <geggam692000 () yahoo com> To: full-disclosure () lists netsys com Subject: [Full-disclosure] TCP / IP Date: Sat, 16 Oct 2004 16:49:52 -0700 (PDT) I am just a student learning about TCP/IP and dont know where to post this idea, figured posting it here would get me some flames and links. Why not make the window the size of the file to be transmitted and the ack back have the segments missing thereby reducing overall overhead and lag time. ie host1 1mb file --- sent -- > host2 host1 <-- ack missing 3 6 8 segments -- host2 host1 -- segments 3 6 8 sent ---> host2 host1 <-- FIN --- host2 The window could be dynamic according to content size. Buffers would have to be huge but with RAM so cheap these days why not ? or am I smoking newbie crack ? Dan __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
-- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT/CS d- s: a-- C++++$ ULS++++$ P L+++ E--- W- N+ o? K? w-->--- O? M->+ V? PS PE Y++ PGP+++ !t 5? X++ R tv-- b++ DI+ D++ G+>+++ e h--- r++ y? ------END GEEK CODE BLOCK------ () ascii ribbon campaign - against html mail /\ - against microsoft attachments
Attachment:
_bin
Description:
Current thread:
- TCP / IP D B (Oct 16)
- Re: TCP / IP Honza Vlach (Oct 17)
- <Possible follow-ups>
- RE: TCP / IP D B (Oct 16)
- Re: TCP / IP lee . e . rian (Oct 16)