tcp window size

I've been reading a bunch of stuff on this topic, understanding some, being baffled by the rest, BUT... from what i've understood, changing the tcp window size lets u raise the maximum size of a packet that you can recieve, but the catch is that you cant change the amount that the server will send to you. But if were to write a client and a server, and set the window size on both very high, does this mean that i could transfer huge chunks of data, im assuming up to the max bandwith limit my ISP allows? If i can do this, does this have some adverse affects on the network?

I am currently working on a Networking project myself. You can change the packet size on the client and server. It depends on what you are doing as to weather or not a large packet can have a negative effect. For instance, the project I am working on requires speed more than anything. Sending larger packets would seem to transfer the data faster as you are sending larger chunks but what happens if one of those large chunks gets lost or dropped along the way? You have to resend the whole thing. Now that can be very bad. If you send the same data over smaller packets if one gets lost you only need to resend a small piece. Wich in the end is quicker then send the big one all over again. Also you have to think about the equipment on the internet between the client and server. Routers will tare apart your huge packet into little pieces if it needs to to fit the huge packet across a little line where another router will have to reassemble it. Wich takes time as well. Basically you really need to think about what you are trying to achive and about how that packet will get there and what might happen to it along the way. But that is just my opinion. I hope it helps

hmm that's interesting. i guess what i need to figure out is relationship between packets size and packet loss. i also hadnt thought about other routers breaking it up into pieces. question though: when packets are dropped, tcp handles that without user interference, yes? what i mean is, tcp will "know" a packet was dropped when it doesnt recieve an ACK, and resend the packet without telling you about it, correct? but if i were to use tcpdump, i would be able to tell how many had to be resent i think

For more information, you might want to check out TCP/IP Illustrated Volume I. There're a few chapters dedicated to interactive vs. bulk transfer with TCP protocol and he discusses the Sliding Window and Nagle algorithm in depth as well.

This RFC is pretty much devoted to the topic. im only about 1/2 way thru but it's already answered a bunch of the questions i had.... but sometimes i wonder how valid it is being that it's 15+ years old

ftp://ftp.rfc-editor.org/in-notes/rfc813.txt

This is a big subject and probably a good research subject.

This site seemed to offer a fairly good discussion:
Tuning End Systems
http://www.gmd.de/Topics/ATM/tuning/