Thanks Rod! That was very educational. I just might be busy on Friday. Chris
> Chris BONDE wrote: > > Daniel: > > Sorry, for placing on discuss. I am still learning, where and what, > > for the lists. > > > > I figured that I would not use the amount of download but curious. > > You answered the implied question, however, the part that I am still > > wondering about, and, I realize that it doesnot matter a twit, is > > the calculation. > > > > One part is in bits per second the other GB per month. > > > > When most people refer to 8 bit bytes, they are just talking about > > the data, not the rest of the message, or envelope etc. That is > > what I would like to clear up in this fossilizing brain. Parity > > and/or check bits, header and trailer or envelope bytes, these must > > add another 15% to the size of the data. ne c'est pas? > > > > Chris > > I'll take a stab at this, networking is my chosen profession. > > There is really no fixed percentage that you can figure on for this. > It depends on exactly where you want to start from and what kind of > data you are transmitting. > > Take this email message for example. I'm looking at a bunch of > characters on a screen and I could count those characters and arrive > at a byte count for the message. I have this set for plain-text, but > if I had it set for html format, there would be additional characters > in the message that I wouldn't directly see or be able to count. When > I press "send" the e-mail program will prepend the e-mail header which > you can view (in Mozilla, CNTL-U). That's the first layer of > encapsulation - the Application layer. > > Next is the Transport Layer. In this case, the TCP protocol. It will > break the message up into appropriate sized pieces (generally between > 600 to 1500 bytes), negotiate a connection with the other end, and > encapsulate the bytes in a header with port numbers and sequencing > numbers. This is called a datagram. > > In some applications there can be an additional layer between the > Transport and Application. An example is the Real Time Transport > protocol that is used for streaming media such as Internet phone. This > adds it's own header and sequencing information to the message. > > After the Transport layer is the Internet layer. IPv4 adds at least 20 > octets of IP addresses and various flag bits to the message. Different > options can add to this overhead. This is now called a packet. > > Overall, you are looking at about 32 to 40 bytes of overhead for every > packet. In addition, it is possible that the packet can be further > fragmented by routers in the path. Each fragment is a full-fledged IP > packet in it's own right and the fragments aren't reassembled until > they arrive at your machine. This doesn't happen so much anymore, but > it is still possible. > > The packets get further encapsulated at the Data Link and Physical > layers into frames, but I think it's safe to assume that your ISP is > measuring at the packet level. > > Bottom line is that it depends a lot on what you're sending or > receiving. An ftp download probably has around 1-2% overhead, while a > short e-mail message may see closer to 100-200%. Web-surfing is > probably > in the 5% range give or take. Every message will be different. > > There will be a quiz on Friday. :) > > Rod
