Re: [IRCA] Posting DX Audio Clips
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IRCA] Posting DX Audio Clips





>Beyond this overhead, add the overhead that TCP/IP protocols
>induce as well.  The 8 bit data effectively becomes 10 bits
>when averaged out.
>
>Mike


The overhead that TCP (layer 4 of the OSI model) and IP (layer
3) add will indeed make the entire message at the frame
layer (2) longer, but this has nothing to do with the structure
and content of the actual data message, which is at higher
OSI layers, as each byte of data always will have 8 bits,
regardless of how the bits are assigned. The overhead of
IP (addressing) and TCP (guarantee of delivery) are added
IN FRONT OF the data content, of each frame.

Learn those 7 layers and why they exist.

The TCP and IP headers, and the MAC layer (2) header add a bit
less than 60 bytes, no matter the size of the data payload.
This makes protocols like telnet very inefficient as you need 64 bytes
to send a single payload character. A FTP (file TRANSFER protocol)
exchange will use the maximum MTU of the data-link protocol,
which can be 1480 bytes of data, or 1518 of frame, and is much
more efficient in terms of overhead. Then, the way windowing is
handled (no. of frames sent before an ACK is needed) will further
affect the efficiency of the transfer.


>"W. Curt Deegan" <WWWR@xxxxxxxxxxxxx> wrote:
>Steve,
>
>Email clients and servers only handle character data which is 6 bits.
>Binary data is 8 bits. To send binary data files the 8 bit data is
>broken down into groups of 6 bit data which looks like characters, then


The low-order ascii character set, consisting of 128 chcracters,
ranging from 00 hex to 7f hex, need 2^7 or 128 possible bit
combinations, which is 7, not 6. The extended character set goes to
twice
that, or 256, and the extra high bit makes it 8 bits needed to encode
256
possible chcracters. And, EBCDIC (IBM mainframe) also uses a
8bit character field.  So yes, binary data is 8 bit.    All data is 8
bit.

The old serial data protocols used the high bit for parity (7E1, etc, or
8N1 for No parity), and there may have been 1 or 2 "stop" bits, being
asynchronous (not clocked) so each bit could be tracked. In TCP
the checksumming is done at the data/frame  level and not the byte
level, so all 8 bits can be used for data content. It is the presence
of the old "stop" bits that led to the idea of more than 8 bits of data
(which affected throughput) per character on serial links.

Yes I know it's not DX, sorry.

If there is a good, open, free website for posting audio content, I hope
to post my old 1960's and 1970's clips, when I get them processed.
Someday soon I hope.


- Bob                  0838 edt




_______________________________________________
IRCA mailing list
IRCA@xxxxxxxxxxxxxxxx
http://arizona.hard-core-dx.com/mailman/listinfo/irca

Opinions expressed in messages on this mailing list are those of the original contributors and do not necessarily reflect the opinion of the IRCA, its editors, publishing staff, or officers

For more information: http://www.ircaonline.org

To Post a message: irca@xxxxxxxxxxxxxxxx