{"id":2668,"date":"2016-03-17T21:46:51","date_gmt":"2016-03-17T21:46:51","guid":{"rendered":"https:\/\/stevepedwards.today\/DebianAdmin\/?p=2668"},"modified":"2025-12-30T18:35:13","modified_gmt":"2025-12-30T23:35:13","slug":"encapsulation-from-bits-to-gigabytes-in-200-years-2","status":"publish","type":"post","link":"https:\/\/stevepedwards.today\/DebianAdmin\/encapsulation-from-bits-to-gigabytes-in-200-years-2\/","title":{"rendered":"Encapsulation – From Bits to Gigabytes in 200 Years"},"content":{"rendered":"
<\/div>\n

<\/path><\/svg><\/i> \"Loading\"<\/p>\n

<\/div>\n

Encapsulation comes in many forms and in my opinion is often overlooked and under-reported as a major concept in many IT, telecoms, computer, networking or other binary based technical courses.<\/p>\n

We don't even teach visualising \"encapsulation\" with the perfect explanatory image of a Russian Doll, yet most children are familiar with that.<\/p>\n

\"\"For me, encapsulation is about the most important concept in computing, as our language is also based on it and follows rules or protocols;<\/strong><\/em> letters make words, words make sentences, sentences make paragraphs, to pages, chapters, books, libraries and so on.<\/p>\n

Our mathematical systems are described by it; decimal units are grouped in tens, tens into hundreds etc.<\/p>\n

Encapsulation of data organised as useful information - a foundational database concept - exactly the concept we used to create computer systems and be able to program them to be useful tools in the first place.<\/p>\n

Data encapsulation occurs from L7 to L1 and decapsulation from L1 to L7.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
OSI Layer<\/th>\nTerm<\/th>\n<\/tr>\n<\/thead>\n
Layer 7 \u2013 Application L7 PDU (Protocol Data Unit)<\/td>\nData (Application and Service Advertisement (e.g. a Net printer), POP3, IMAP - (NOT the actual App like Outlook!)<\/td>\n<\/tr>\n
Layer 6 \u2013 Presentation L6 PDU<\/td>\nData (data formatting, encryption (TLS, SSL), ASCII, JPG, PNG, MP4, Script languages)<\/td>\n<\/tr>\n
Layer 5 \u2013 Session L5 PDU<\/td>\nData (H323, NetBIOS, RTP, PPTP, CHAP )<\/td>\n<\/tr>\n
Layer 4 \u2013 Transport<\/td>\nSegments (TCP)\/Datagrams (UDP)<\/td>\n<\/tr>\n
Layer 3 \u2013 Network<\/td>\nPackets<\/td>\n<\/tr>\n
Layer 2 \u2013 Data Link<\/td>\nFrames<\/td>\n<\/tr>\n
Layer 1 \u2013 Physical<\/td>\nBits<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

If you don't understand the difference between data and information, read my 2nd year degree-level Databases research paper in the top menu links.<\/p>\n

The basic principle of encapsulation - smaller units of something being grouped into fixed size, larger and larger containers for ease of transport and administration - is nothing new, if you think of how goods are transported round the world every day (letters in envelopes, envelopes in packets, packets in parcels, parcels in boxes etc.) - so why is this important concept and the protocols that define those methods left to the side so much, if broached at all in many beginner-level tech courses, where a brief explanation of data accumulation (storage in some form no matter how long or short the time period) should be obvious to mention because it's everywhere in digital computing in some form at every moment!?<\/p>\n

Without encapsulation and the protocols that count and order them according to design requirements, everything is just a collection of 1s and 0s either streamed, or held in a static magnetic or electrical field.<\/p>\n

So how are these bits structured and re-arranged to have meaning in human reality?<\/p>\n

The Database paper outlines a database<\/em>\u00a0specific<\/em> set of methods, but there are many other ways - depending on design\u00a0 requirements - as you would expect if data is \"everywhere\" - and nowadays, it pretty much is!<\/p>\n

I'd define the Internet that way - available everywhere - if you have the right gear, anywhere on the planet, you can connect to a satellite at least.<\/p>\n

What are some ways encapsulation can be shown more specifically in the various systems that make up a computer environment?<\/p>\n

In most systems, bits are most commonly stored either on a hard drive or memory chips.<\/p>\n

First, an example of hard drive encapsulation.<\/p>\n

In a directory or file listing using ls -l of various formats, there's a lesser-known column, before the modification date<\/em><\/strong>, that states numerical info on those files, but what is it?<\/p>\n

You could google and get an answer immediately, but let's see if a Linux command jigsaw puzzle approach can work with research, to learn some new commands in the process, by seeing if man<\/span> can supply info on relevant terms.<\/p>\n

First, create an empty file:<\/p>\n

Mint5630 SEDAWK # touch testfile.txt<\/span><\/p>\n

Mint5630 SEDAWK # ls -l testfile.txt <\/span><\/p>\n

-rw-r--r-- 1 stevee stevee 0<\/strong> Oct 3 16:28 testfile.txt<\/span><\/p>\n

First, briefly, the other better known fields in that output are:<\/p>\n

file type (-);<\/p>\n

read,write,exe (rwx) permissions (x3) for user,group,others; file links (1); user (owner, stevee); group (membership, stevee); ??(0)<\/strong>; modification time (date);<\/p>\n

filename<\/p>\n

So what does this number 0<\/strong> mean before the modification time\/date <\/strong>stamp?Is it the same as \"allocated size in blocks\" as stated in man, as we know it's an empty file?<\/p>\n

man ls<\/span><\/p>\n

-s, --size<\/span><\/p>\n

print the allocated size of each file, in blocks<\/span><\/p>\n

stevee@Mint5630 ~ $ ls -ls testfile.txt<\/span><\/p>\n

0<\/strong> -rw-r--r-- 1 stevee stevee 0 <\/strong>Oct 3 16:28 testfile.txt<\/span><\/p>\n

No, because this gives a new field (0) at the start, though the number is the same;<\/p>\n

so has it just been repeated or is it something else? Unix wouldn't be pointlessly repetitive in that way.<\/p>\n

If I append some data to the empty file, say, the A character, without a new line character, will anything change?:<\/p>\n

stevee@Mint5630 ~ $ echo -n A >> testfile.txt <\/span><\/p>\n

stevee@Mint5630 ~ $ ls -ls testfile.txt <\/span><\/p>\n

4<\/strong> -rw-r--r-- 1 stevee stevee 1<\/strong> Oct 3 16:43 testfile.txt<\/span><\/p>\n

Ah, now there is an indication of something else - but what?<\/p>\n

The 0 changes to a 1, of whatever it is. A bit?; byte?; block? - and the first 0 changes to a 4<\/p>\n

What does \"human readable\" say?<\/p>\n

stevee@Mint5630 ~ $ ls -lsh testfile.txt <\/span><\/p>\n

4.0K -rw-r--r-- 1 stevee stevee 1 Oct 3 16:43 testfile.txt<\/span><\/p>\n

Seems the 1 does not measure a standard data bit size multiple in terms of bits or bytes etc., but the 4K does.<\/p>\n

If the smallest unit of data is a 1 or 0, or a \"bit\", what are the various ways they can accumulate and be named as data-bit multiples? It turns out, depending on what they are being used for to describe useful information say characters, numbers, packets etc. - they can accumulate in many ways with many different names, for both historic and current technological reasons.<\/p>\n

Better find out what each of the most fundamental bits are first, then what fundamental groupings they can become regardless of what medium they are stored on or streamed across.<\/p>\n

https:\/\/en.wikipedia.org\/wiki\/Bit<\/span><\/a><\/span><\/p>\n

\"The bit is not defined in the International System of Units (SI). However, the International Electrotechnical Commission issued standard IEC 60027, which specifies that the symbol for binary digit should be bit, and this should be used in all multiples, such as kbit, for kilobit.[7] However, the lower-case letter b is widely used as well and was recommended by the IEEE 1541 Standard (2002). In contrast, the upper-case letter B is the standard and customary symbol for byte\u00a6 <\/em><\/h2>\n

For convenience of representing commonly reoccurring groups of bits in information technology, several units of information have traditionally been used. The most common is the unit byte, coined by Werner Buchholz in July 1956, which historically was used to represent the number of bits used to encode a single character of text (until UTF-8 multibyte encoding took over) in a computer[8][9] and for this reason it was used as the basic addressable element in many computer architectures. <\/em><\/h2>\n

The trend in hardware design converged on the most common implementation of using eight bits per byte, as it is widely used today. However, because of the ambiguity of relying on the underlying hardware design, the unit octet was defined to explicitly denote a sequence of eight bits.\"<\/em><\/span><\/h2>\n

So, small k + small b = kilobit = 1000 bits<\/p>\n

Large B = byte = octet = 8 bits<\/p>\n

https:\/\/www.tldp.org\/LDP\/sag\/html\/filesystems.html<\/span><\/a><\/span><\/p>\n

\"Most UNIX filesystem types have a similar general structure, although the exact details vary quite a bit. The central concepts are superblock, inode,data block<\/strong>, directory block, and indirection block. The superblock contains information about the filesystem as a whole, such as its size (the exact information here depends on the filesystem). An inode contains all information about a file, except its name. The name is stored in the directory, together with the number of the inode. A directory entry consists of a filename<\/strong> and the number of the inode which represents the file. The inode contains the numbers of several data blocks, which are used to store the data in the file.<\/strong> There is space only for a few data block numbers in the inode, however, and if more are needed, more space for pointers to the data blocks is allocated dynamically. These dynamically allocated blocks are indirect blocks; the name indicates that in order to find the data block, one has to find its number in the indirect block first\u00a6 <\/span><\/em><\/p>\n

5.10.5. Filesystem block size<\/strong><\/p>\n

The block size specifies size that the filesystem will use to read and write data. Larger block sizes will help improve disk I\/O performance when using large files, such as databases. This happens because the disk can read or write data for a longer period of time before having to search for the next block. On the downside, if you are going to have a lot of smaller files on that filesystem, like the <\/span>\/etc<\/span>, there the potential for a lot of wasted disk space. For example, if you set your block size to 4096, or 4K, and you create a file that is 256 bytes in size, it will still consume 4K<\/strong> of space on your harddrive. For one file that may seem trivial, but when your filesystem contains hundreds or thousands of files, this can add up.\"<\/span><\/em><\/span><\/p>\n

So, it seems my testfile.txt - may be made up of one or more data blocks, each of a size that depends on what has been set by the file system type in current use, and the amount of those blocks used for the file space indicates the total size allocated on disk.<\/p>\n

How do you find out what the default block size of your file system is? First, you have to know your FS type:<\/p>\n

stevee@Mint5630 ~ $ sudo blkid <\/span><\/p>\n

\/dev\/sda1: UUID=\"436a55a9-f610-45f6-866d-a72bfe10ff74\" TYPE=\"ext4<\/strong>\"<\/span><\/p>\n

man ext4<\/span><\/p>\n

DESCRIPTION<\/span><\/p>\n

The second, third, and fourth extended file systems, or ext2, ext3, and<\/span><\/p>\n

ext4 as they are commonly known, are Linux file systems that have his<\/span>torically <\/span><\/p>\n

been the default file system for many Linux distributions.<\/strong> <\/span><\/p>\n

This ext4 feature allows the mapping of logical<\/span><\/p>\n

block numbers for a particular inode to physical<\/span><\/p>\n

blocks on the storage device to be stored using an<\/span><\/p>\n

extent tree, which is a more efficient data struc<\/span><\/p>\n

ture than the traditional indirect block scheme used<\/span><\/p>\n

by the ext2 and ext3 file systems. The use of the<\/strong><\/span><\/p>\n

extent tree decreases metadata block overhead,<\/strong><\/span><\/p>\n

improves file system performance and decreases the<\/strong><\/span><\/p>\n

needed to run e2fsck(8) on the file system.<\/strong> <\/span><\/p>\n

I can find out the sector size and block size of my hard drive:<\/p>\n

stevee@Mint5630 ~ $ sudo blockdev --report \/dev\/sda1<\/span><\/p>\n

RO RA SSZ BSZ <\/strong> StartSec Size Device<\/span><\/p>\n

rw 256 512 4096<\/strong> 2048 37860933632 \/dev\/sda1<\/span><\/p>\n

Seems the actual physical disk sector size is 512 bytes long, with 8 of those creating an EXT4 blocksize of 4096 bytes.<\/p>\n

So now, it seems I found enough info to assume that my tiny, 1 character content testfile.txt occupies 1\u00a0ext4 file system\u00a0<\/em><\/strong>block (the minimum possible amount to store actual data, rather than mark it as 0 blocks, or empty) of data, of 4096 bytes or 4K space size that has been allocated for it, even if it does not fill it.<\/p>\n

Indeed, this is what the ls -lsh output showed above:<\/p>\n

stevee@Mint5630 ~ $ ls -lsh testfile.txt <\/span><\/p>\n

4.0K<\/strong> -rw-r--r-- 1 stevee stevee 1<\/strong> Oct 3 16:43 testfile.txt<\/span><\/p>\n

Initially, the sector allocation size does not seem to fit with what the default<\/em><\/strong> output of stat<\/span> says:<\/p>\n

stevee@Mint5630 ~ $ sudo stat testfile.txt <\/span><\/p>\n

File: 'testfile.txt'<\/span><\/p>\n

Size: 1 <\/strong>\u00a0\u00a0\u00a0\u00a0Blocks: 8 \u00a0 IO Block: 4096<\/strong> regular file<\/span><\/p>\n

Device: 801h\/2049d\u00a0\u00a0\u00a0\u00a0Inode: 535929 Links: 1<\/span><\/p>\n

Access: (0644\/-rw-r--r--) Uid: ( 1000\/ stevee) Gid: ( 1000\/ stevee)<\/span><\/p>\n

Access: 2015-10-02 23:15:01.695360490 +0100<\/span><\/p>\n

Modify: 2015-10-02 23:14:57.163233200 +0100<\/span><\/p>\n

Change: 2015-10-02 23:14:57.163233200 +0100<\/span><\/p>\n

Birth: -<\/span><\/p>\n

This implies 8 blocks of 4096 bytes each, or 2^15 or 32768 bytes, or 32K of space allocated which there obviously is not - so what is wrong here?<\/p>\n

This seems to be the different stat definition of a \"block\", as different from the ext4 \"block\" shown earlier. A difference between the base hard drive sector<\/strong> size block of 512 bytes, and how the ext4 default filesystem has been organised, as defined for ext 4 above in file system<\/em> block size of 4096 bytes or 4K bytes. This would then make sense, as 8 blocks of 512 bytes per sector, make 1 file system IO block of 4096 bytes.<\/p>\n

Be aware of the base sector size of a hard drive, organised (as multiples) to form a particular file system IO block, of given size. One FS block encapsulates<\/strong> 8 drive sectors, to form a larger storage\/transport unit!<\/p>\n

We have seen this sector to file system variation already with the dd command Posts, where you can change the IO blocksize to suit your hardware's optimal performance to speed up copying time:<\/p>\n

https:\/\/stevepedwards.today\/DebianAdmin\/cool-command-1-dd-progress\/<\/span><\/a><\/span><\/p>\n

Read info coreutils 'stat invocation'<\/span><\/p>\n

Due to shell aliases and built-in `stat' functions, using an<\/span><\/p>\n

unadorned `stat' interactively or in a script may get you different<\/span><\/p>\n

functionality than that described here. Invoke it via `env' (i.e.,<\/span><\/p>\n

`env stat ...') to avoid interference from the shell. <\/span><\/p>\n

`-c'<\/span><\/p>\n

`--format=FORMAT'<\/span><\/p>\n

Use FORMAT rather than the default format. FORMAT is<\/span><\/p>\n

automatically newline-terminated, so running a command like the<\/span><\/p>\n

following with two or more FILE operands produces a line of output<\/span><\/p>\n

for each operand:<\/span><\/p>\n

$ stat --format=%d:%i \/ \/usr<\/span><\/p>\n

2050:2<\/span><\/p>\n

2057:2<\/span><\/p>\n

The valid FORMAT directives for files with `--format' and `--printf'<\/span><\/p>\n

are:<\/span><\/p>\n

* %b - Number of blocks allocated (see `%B')<\/span><\/p>\n

* %B - The size in bytes of each block reported by `%b'<\/span><\/p>\n

So now, if you use the --format option with the %b or %B, things become clearer again, as sector block sizes and amount are stated by the %b and %B formats:<\/p>\n

Mint5630 stevee # stat --format %b testfile.txt <\/span><\/p>\n

8<\/span><\/p>\n

Mint5630 stevee # stat --format %B testfile.txt <\/span><\/p>\n

512<\/span><\/p>\n

This also gives the same values of 8 sector blocks x 512 bytes = 4096 bytes or 4K as ls -lsh does for this file.<\/p>\n

So far, all that explains the disk and file system storage allocated to store the file, but what about the file contents itself?<\/p>\n

Interestingly at this point, the nemo-terminal<\/span> shows two different values for testfile.txt size. The command line shows IO block allocation, and the GUI shows the file contents size 1 character per byte? Handy if so!<\/p>\n

\"\"<\/p>\n

This allows a theory check for whether each character contained in a file IS a byte in size. So let's append some more to it:<\/p>\n

stevee@AMDA8 ~\/Documents $ echo -n BCDEFGH >> testfile.txt <\/span><\/p>\n

stevee@AMDA8 ~\/Documents $ ls -alsh testfile.txt <\/span><\/p>\n

4.0K -rw-r--r-- 1 stevee stevee 8 Oct 6 18:57 testfile.txt<\/span><\/p>\n

Sure enough above, the IO block size of 4k remains unfilled, but the GUI shows 8 bytes total after the addition of another 7 characters. Seems each ASCII character is a byte (8 bits) in size!<\/p>\n

\"\"\"\"Not convinced?<\/p>\n

rm -v testfile.txt<\/span>
\nremoved \u02dctestfile.txt,<\/span>
\nfor x in {1..4096}; do echo -n A >> testfile.txt; <\/span>
\ndone<\/span>
\nls -als testfile.txt<\/span>
\n4 -rw-r--r-- 1 stevee stevee 4096<\/strong> Aug 8 11:29 testfile.txt<\/span><\/p>\n

\"4096k.png\"<\/a><\/p>\n

The programs od and hexdump can output characters in octal\/hex\/denary bytes, and much more if you want to see what octet numbers relate to ASCII characters etc.<\/p>\n

-b One-byte octal display. Display the input offset in hexadecimal,<\/span><\/p>\n

followed by sixteen space-separated, three column, zero-filled,<\/span><\/p>\n

bytes of input data, in octal, per line. <\/span><\/p>\n

-c One-byte character display. Display the input offset in hexadec<\/span><\/p>\n

imal, followed by sixteen space-separated, three column, space-<\/span><\/p>\n

filled, characters of input data per line. <\/span><\/p>\n

-C Canonical hex+ASCII display. Display the input offset in hexa<\/span><\/p>\n

decimal, followed by sixteen space-separated, two column, hexa<\/span><\/p>\n

decimal bytes, followed by the same sixteen bytes in %_p format<\/span><\/p>\n

enclosed in ``|'' characters. <\/span><\/p>\n

Calling the command hd implies this option.<\/span><\/p>\n

-d Two-byte decimal display. Display the input offset in hexadeci<\/span><\/p>\n

mal, followed by eight space-separated, five column, zero-filled,<\/span><\/p>\n

two-byte units of input data, in unsigned decimal, per line. <\/span><\/p>\n

So now I know that a single ASCII non-control character in this file is only 1 byte in size:<\/p>\n

stevee@Mint5630 ~ $hexdump -bcCd testfile.txt<\/span><\/p>\n

\"hexd.png\"<\/a><\/p>\n

You can see that \"A\" has the same numerical value = 41<\/strong> or (4 x16 = 64 +1) =\u00a065<\/strong> in base 10; = 101<\/strong> (8x8+0+1 = 65<\/strong>) in octal; if you do the maths. stevee@AMDA8 ~\/Desktop $ od -b testfile.txt<\/span>
\n0000000 101<\/strong> 102 103 104 105 106 107 110<\/span>
\n0000010<\/span><\/p>\n

The actual contents of the original file with just the A in it is 3 bytes it seems A Null, the A itself, and a Start Of Heading control character, 0000001. As the other 2 are control characters they don't show in the nemo window size column, just the A does, as 1 byte.<\/p>\n

stevee@AMDA8 ~\/Desktop $ hd -b testfile.txt<\/span>
\n00000000 41 |A|<\/span>
\n0000000 101 <\/span>
\n0000001<\/span><\/p>\n

That may be interesting to research as why the other non-printable, control characters of only 1 bit in size each, don't also register a byte length allocation in the GUI?<\/p>\n

The first all 0s would make sense not to, as all 0s don't take up \"registered\" disk space as far as I know, but the Start Of Heading character is a 1?<\/p>\n

ASCII control characters (character code 0-31)<\/h2>\n

The first 32 characters in the ASCII-table are unprintable control codes and are used to control peripherals such as printers.<\/p>\n

\n\n\n\n\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n
\n

DEC<\/strong><\/span><\/p>\n<\/td>\n

\n

OCT<\/strong><\/span><\/p>\n<\/td>\n

\n

HEX<\/strong><\/span><\/p>\n<\/td>\n

\n

BIN<\/strong><\/span><\/p>\n<\/td>\n

\n

Symbol<\/strong><\/span><\/p>\n<\/td>\n

\n

HTML Number<\/strong><\/span><\/p>\n<\/td>\n

\n

HTML Name<\/strong><\/span><\/p>\n<\/td>\n

Description<\/strong><\/span><\/td>\n<\/tr>\n
\n

0<\/span><\/p>\n<\/td>\n

\n

000<\/span><\/p>\n<\/td>\n

\n

00<\/span><\/p>\n<\/td>\n

\n

00000000<\/span><\/p>\n<\/td>\n

\n

NUL<\/span><\/p>\n<\/td>\n

\n

\n<\/td>\n

<\/td>\nNull char<\/span><\/td>\n<\/tr>\n
\n

1<\/span><\/p>\n<\/td>\n

\n

001<\/span><\/p>\n<\/td>\n

\n

01<\/span><\/p>\n<\/td>\n

\n

00000001<\/span><\/p>\n<\/td>\n

\n

SOH<\/span><\/p>\n<\/td>\n

\n

\u0001<\/span><\/p>\n<\/td>\n

<\/td>\nStart of Heading<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

What system defines alphabetic or other \"characters\" that are used in an allocated file \"space\"?<\/p>\n

To answer that adequately, a history lesson is required, as there are also many other aspects of today's IT systems, such as security, privacy, efficiency, statistical analysis, overhead etc. that were also present, with historical hindsight, even if the implications were not fully realised or intended at inception in more primitive forms of electrical telecoms.<\/p>\n

Historically there have been many coded transmission systems, and their origins lie in older forms of \"networking\" as we know it now, or \"signals transmission\" of one sort of another, that were around long before electricity was discovered - smoke signals, drums, bonfire beacons, flag semaphore etc.<\/p>\n

These are self-explanatory for the most part, and may just have signified an \"event\" of some sort, but the important thing to note is that the event or non-event represents a form of binary boolean signalling; if x happens, light fire!; if not, don't!<\/p>\n

Jumping to electrical signals, the Morse Code superseded the forms of visual (and public) long distance semaphores, to transmit pulses in a circuit, (which also implies a basic level of security as only the sender and receiver know the message).<\/p>\n

This system comprised a series of time-dependent pulses - with a base \"protocol\" defining dots and dashes in terms of those time-based pulses - where the duration of a dash equalled 3 dots, and the time between each pulse also equalled a dot duration.<\/p>\n

https:\/\/en.wikipedia.org\/wiki\/Morse_code<\/strong><\/a><\/p>\n

If viewed as an encapsulation method, Morse is interesting as it combines elements of a minimum \"element\" size (a dot or space) and a maximum \"elemental unit combination\" size of 5 dashes separated by 4 dots for the longest character, \"0\":<\/p>\n

\"\"<\/p>\n

If this was seen as time pulses, then character 0 would comprise (5x3 dots) + (4 dots) = 19 dot lengths.<\/p>\n

All the number and letter characters could be contained within a larger \"encapsulated unit\" of 19 pulses time duration - or any other term you may like to call them - maybe a box? envelope? parcel? or even...a Packet? a Datagram? a Frame..? a Container?<\/p>\n

This \"protocol\" would be \"structurally inefficient\" but \"practically efficient\" in today's technological terms, as the actual \"Morse code design\" had already been optimised for transmission speed (efficiency) by humans, using statistical analysis, so the reason the \"E\" has the shortest duration of 1 dot length - because it is the most common letter in most English language words, so the quickest to transmit by hand. Clever stuff.<\/p>\n

This \"statistically optimised\" design would be compromised if all the characters were \"encapsulated\" in a framework of a fixed length of 19 pulses. This would of course be irrelevant if transmitted automatically, using a 19 dot length \"packet\", by an automated system that could transmit a dot length more than about 19 times faster than a human, if only because it would be so convenient - despite the loss of job for the transmission clerk!<\/p>\n

Studying systems like this, it can be seen that it has been realised that there has to be a minimum 3 dot length separation between characters to avoid confusion between the characters that end with a stream of dots, and those that start with dots. The same logical separation exists for words, with a gap of 7 dot lengths, which is the same duration as a letter D, H or M, but made of silence.<\/p>\n

If the minimum dot length in Morse is seen as an equivalent of a 1 or 0 in today's binary systems, it can be seen that binary is more efficient in describing the characters if each is \"encapsulated\" within a byte length, because the 26 letters of the English alphabet could be ascribed numbers 1-26 in binary, which takes only 5 binary bits to range from 1-26, which is [00001 11010] in binary. The maximum character dot length in Morse is 19 \"time pulses\" long, as seen above. One octet of binary only requires 8 bits or \"dots\", and depending on how you defined a \"byte\", then 5 bits would suffice to cater for all 26 alphabet letters A-Z.<\/p>\n

\"\"<\/p>\n

Even if the numbers 0-9 are included, this gives 36 characters, that can be described in binary with only 1 more digit, the 2^5, or 32 bit column, for 6 bit length byte characters.<\/p>\n

One of the earliest systems to use a 5 bit \"byte\" system was the Baudot Code which could be used for telegraphic transmission and is still an unused standard today:<\/p>\n

\"Baudot's code became known as International Telegraph Alphabet No. 1<\/strong>, and is no longer used.\"<\/em><\/p>\n

https:\/\/en.wikipedia.org\/wiki\/Baudot_code<\/span><\/a><\/span><\/p>\n

Baudot code developed from Bacon's Cipher:<\/p>\n

https:\/\/en.wikipedia.org\/wiki\/Bacon%27s_cipher<\/span><\/a><\/span><\/p>\n

which can be seen as an equivalent of binary bytes, if char A represents binary 0, and char B represents binary 1. As \"u=v\"and i=j, all letters are described by 24 x 5 character \"digits\" as above, from 00000 (a) to 10111 (z):<\/p>\n

a AAAAA g AABBA n ABBAA t BAABA<\/p>\n

b AAAAB h AABBB o ABBAB u-v BAABB<\/p>\n

c AAABA i-j ABAAA p ABBBA w BABAA<\/p>\n

d AAABB k ABAAB q ABBBB x BABAB<\/p>\n

e AABAA l ABABA r BAAAA y BABBA<\/p>\n

f AABAB m ABABB s BAAAB z BABBB<\/p>\n

The encapsulation is in the form of 5 elements per character block, and can be translated to a present-day equivalent of a time-dependent bit stream of square wave clock pulses, where each pulse represents a possible 0 or 1 bit value:<\/p>\n

\"\"<\/p>\n

A peak represents a B, or 1, and a trough is an A or 0.<\/p>\n

Each character block is then delimited and so defined by an external reference clock source, that relentlessly beats time at exact intervals between each character's only allowed existence period of 5 pulses, at an amplitude of 0 or 1 only per pulse, with a counter system of some sort marking each contiguous block of 5 time periods.<\/p>\n

In a similar fashion to the Morse letter and word separator, there would need to be a period and\/or pattern of pulses that represented a gap between character types, whose binary value was not equal to any of the letter or number characters. The rule set - or protocol - defining all these various parameters that may be required in a functional transmission system i.e. bits per byte, clock pulse source and pulse counter technology, pulse duration in seconds, delimiter byte value, start of message byte value or pattern, end of message byte value or pattern, error detection methods, retransmission of lost bytes, methods of synchronisation at each end, limits of technology - and overall system design for purpose.<\/p>\n

It is only when spelled out in those terms that you realise how much is present but taken for granted in the control system of Morse Code, when humans are doing it naturally, using our own language \"protocols\" to determine timing aspects like \"message start and end\", \"garbled message\", negotiated speed of transmission and etiquette, that you think how complicated it all is to translate for a machine to do it.<\/p>\n

That form of counting regularly spaced clock pulses it a \"time-dependent\" coding, and all bits are organised so they fall in step either singularly or in defined blocks - with a Master Clock of some form.<\/p>\n

Using a very fast electronic clock source enabled a particularly efficient method of sending many signals seemingly \"simultaneously\", called Time Division Multiplexing TDM.<\/p>\n

This is a method of combining multiple \"conversations\" or messages along the same media (copper wire, optical fibre, Wi-Fi etc.) by interspersing small \"chunks\" of each message in a small time space, so sharing the media and clock source \"time space\", using it to transmit seemingly instantaneously - all the separate channel's messages \"at once\" if done quickly enough, compared to a human's rate of perception.<\/p>\n

The graphic example below could be seen as a way of constructing and deconstructing the 5 binary digit \"bytes\" of the Baudot Code above, where each consecutive bit of each Baudot character byte is from a different message stream from 5 different sources.<\/p>\n

\"400px-Telephony_multiplexer_system.gif\"<\/a>
\n<\/strong>This shows that it would take 5 clock pulses to send the first bit of each of the 5 separate messages, before cycling round to send the 2nd<\/sup> bit, then the 3rd<\/sup> and so on. It would take 21 pulses for the first 5 bit byte to be re-assembled by the receiver to decipher the first Baudot letter\/number character for conversation A, and 25 pulses before all conversations had received the first character of their respective message.<\/p>\n

This is a particularly \"democratic\" method of sharing available hardware and technology, so all receive their messages in a more \"fair\" and timely fashion without \"E\" having to wait, last in the queue, until all the others had sent their whole messages first.<\/p>\n

More importantly, it means there does not have to be the cost and engineering involved in creating 5 separate links, 5 encoders, 5 decoders and 5 lots of other associated resources to be built and installed to cover the same geographic area. A MASSIVE construction cost advantage, the larger the scale and distances involved.<\/p>\n

Think current, state-of-the-art, multi-billion dollar, but single cable, optical subsea systems that I have had the good fortune to work on in a past life, that link continents, to appreciate the real benefits of multiplexing and so encapsulation!<\/p>\n

https:\/\/virtuallynao.files.wordpress.com\/2011\/04\/2011_0208_cable_basemap.jpg<\/a><\/p>\n

\"\"<\/a>Multiplexing and demultiplexing has been the cornerstone of digital telegraphy\/telephony (the Internet) since it became publicly available around the 1980s, with the first digital network, TCP\/IP precursor to the modern Internet - DARPANET - sending its first message in 1969.<\/p>\n

https:\/\/en.wikipedia.org\/wiki\/ARPANET<\/span><\/a><\/span><\/p>\n

This network was designed around the concept of \"packet switching\", where packets of data - predefined collections of encapsulated bytes that represent a message part of some type - are transmitted separately across the telephone network, but can take different phone circuit routes as available and required, before being re-assembled in the correct order that they were sent, to recreate the original message. A main driver for this was military comms requirements should any part of a comms link be taken out in a war, then the packets could find alternate routes, and still be delivered and recombined into the original message. Smart idea!<\/p>\n

Initially, the bulk of the data sent over the existing analogue audio frequency telephone network was digitised telephone conversations, using the Integrated Services Digital Network ISDN protocol, described in the older CISCO CCNA course, which covered ISDN in some depth, before it became more or less obsolete and replaced by Digital Subscriber Lines of various types, but describes examples of ISDN encapsulation design:<\/p>\n

There are two ISDN services: BRI and PRI. The ISDN BRI service offers two 8-bit B channels and one 2-bit D channel, often referred to as 2B+D, as shown in the figure. ISDN BRI delivers a total bandwidth of a 144-kbps line into three separate channels (8000 frames per second * (2*8-bit B channel+2 bit D channel)=8000*18 = 144kbps).BRI B channel service operates at 64 kbps (8000 frames per second* 8-bit B channel) and is meant to carry user data and voice traffic.<\/span><\/em><\/strong><\/p>\n

ISDN provides great flexibility to the network designer because of its ability to use each of the B channels for separate voice and\/or data applications. For example, a long document can be downloaded from the corporate network over one ISDN 64-kbps B channel while the other B channel is being used to browse a Web page.<\/em><\/strong><\/p>\n

The third channel, the D channel, is a 16-kbps (8000 frames per second * 2 bit D channel) signalling channel used to carry instructions that tell the telephone network how to handle each of the B channels. BRI D channel service operates at 16 kbps and is meant to carry control and signalling information, although it can support user data transmission under certain circumstances. The D channel signalling protocol occurs at Layers 1 through 3 of the OSI reference model.<\/em><\/strong><\/p>\n

ISDN physical-layer (Layer 1) frame formats differ depending on whether the frame is outbound (from terminal to network-the TE frame format) or inbound (from network to terminal-the NT frame format). Both of the frames are 48 bits long, of which 36 bits represent data. Actually, the frames are two 24 bit frames in succession consisting of 2 8-bit B channels, a 2-bit D channel, and 6 bits of framing information (2*(2*8B+2D+6F) = 32B+4D+12F = 36BD+12F = 48BDF). Both physical-layer frame formats are shown in the figure. The bits of an ISDN physical-layer frame are used as follows:<\/em><\/strong><\/p>\n