Interprocess Communication

Лекція № 17.

Interprocess Communication.

Ми із Вами казали, що далі йдеться про поділюваних ресурсах, доступом до яких може здійснюватися із боку довільних процесів, в загальному разі, в довільному порядку. Ці ресурси доступні будь-якому процесу, а процеси необов’язково повинні прагнути бути родинними. За наявності такий схеми виникають дві принципові проблеми: 1. Називати; 2. Синхронизация;

Проблеми іменування пов’язані про те, що родинних зв’язків немає і з спадщині передати нічого нельзя.

Якщо проблему іменування вирішена, виникає проблема синхронізації доступу — як організувати обмін з ресурсами, щоб ця обмін був коректним. Якщо є, наприклад, ресурс «оперативна пам’ять», то коли той процес ще дописав інформацію, а інший процес вже прочитав весь блок, виникає некоректна ситуация.

Рішення них ми й рассматривать.

Проблема іменування вирішується з допомогою асоціювання з кожним ресурсом деякого ключа. У випадку це целочисленное значення. Тобто за створенні яке поділяється ресурсу його автор приписує йому номер яких і визначає права доступу до цього ресурсу. Після цього будь-який процес, який вкаже системі, що хоче спілкуватися із поділюваним ресурсом з ключем N, і володіє такими необхідними правами доступу, буде допущено до роботи з цим ресурсом.

Але такий рішення перестав бути ідеальним, оскільки цілком можлива колізія номерів — коли збігаються номери поділюваних ресурсів. У цьому вся разі процеси будуть плутатися, неминучими призведе до помилок. Тож у системі передбачено стандартне засіб генерації унікальних ключів. Для генерації унікального ключа використовується функція ftok.

#include.

#include key_t ftok (char *p.s, char c);

Суть його дії - по текстовій рядку і символу генерується унікальне кожної такий пари значення ключа. Після цього сгенерированным ключем можна скористатися як створення ресурсу, і на утвердження використання ресурсу. Понад те, щоб уникнути колізій, рекомендується вказувати як параметра «покажчика на рядок «шлях до певного своєму файлу. Другий аргумент — символьний, що дозволяє створювати деякі варіанти ключа, що з цим ім'ям, цей аргумент називається проектом (project). За такого підходу можна домогтися відсутності коллизий.

Погляньмо конкретні засоби роботи з поділюваними ресурсами.

Розділюваний память.

Загальна схема роботи з поділюваними ресурсами така — є певний процесс-автор, створює ресурс з будь-якими параметрами. Під час створення ресурсу поділюваної пам’яті задаються три параметра — ключ, права доступу і розмір області пам’яті. Після створення ресурсу щодо нього може бути підключені процеси, бажаючі працювати з цим пам’яттю. Відповідно, є дію підключення до ресурсу з допомогою ключа, який генерується за тими правилами, як і ключ до створення ресурсу. Зрозуміло, що тут є момент деякою рассинхронизации, який із тим, що споживач яке поділяється ресурсу (процес, який працюватиме з ресурсом, але з є його автором) то, можливо запущено і почав підключатися перед запуском автора ресурсу. У цій ситуації особливого криміналу немає, оскільки є функцій управління доступом до разделяемому ресурсу, з допомогою яких можна встановити деякі опції, що визначають правила роботи функцій, котрі взаємодіють із поділюваними ресурсами. Зокрема, існує опція, що змушує процес дочекатися появи ресурсу. Це також може бути, трохи зле, наприклад, автор може й не з’явитися, але іншого виходу немає, це є певні накладні витрати. От у загальних словах — що є что.

Давайте розглянемо ті функції, які надаються нам до роботи з поділюваними ресурсами.

Первая функція — створення спільної пам’яті. int shmget (key_t key, int size, int shmemflg); key — ключ поділюваної пам’яті size — розмір розділу пам’яті, що має бути створено shmemflg — флаги.

Ця функція повертає ідентифікатор ресурсу, який асоціюється створеному на цей запит поділюваним ресурсом. Тобто у межах процесу з аналогії з файловими дескрипторами кожному разделяемому ресурсу визначається її ідентифікатор. Треба розділяти ключ — це общесистемный атрибут, і ідентифікатор, використовуючи який ми з конкретним поділюваним ресурсом у межах процесса.

З допомогою цієї функції можна як створити новий поділюваний ресурс «пам'ять» (у разі у прапорах повинен бути вказаний IPC_CREAT)?, і навіть можна підключитися наявному разделяемому ресурсу. З іншого боку, в можливих прапорах то, можливо зазначений прапор IPC_EXECL, вона дозволяє перевірити, і підключитися наявному ресурсу — якщо ресурс існує, то функція підключає щодо нього процес і повертає код ідентифікатора, Якщо ж ресурс немає, то функція повертає -1 і відповідні код в errno.

Следующая функція — доступом до поділюваної пам’яті: char *shmat (int shmid, char *shmaddr, int shmflg); shmid — ідентифікатор яке поділяється ресурсу shmaddr — адресу, із якого ми хотів би розмістити поділювану память.

У цьому, якщо значення shmaddr — адресу, то пам’ять буде підключена, починаючи від цього адреси, якщо його значення — нуль, то система сама підбере адресу початку. Також у ролі значень цього аргументу може бути деякі визначені константи, що дозволяють організувати, в частковості вирівнювання адреси по сторінці чи початку сегмента пам’яті. shmflg — прапори. Вони визначають різні режими доступу, зокрема, є прапор SHM_RDONLY.

Ця функція повертає покажчик на адресу, починаючи від якого буде починатися запрашиваемая розділюваний пам’ять. Коли доходить до помилка, то повертається -1.

Хотів би трохи поговорити про права доступу. Вони реально можуть вживатись і коректно працювати який завжди. Оскільки, якщо апаратно не підтримується закриття області даних для читання чи запис, то цьому разі, можуть виникнути проблеми у реалізації що така прапорів. Уперших, вона буде працювати, адже ми отримуємо покажчик і починаємо працювати із покажчиком, і з покажчиком, і загальна схема не передбачає захисту. Друге, можна програмно зробити, щоб працювали прапори, але ми не зможемо вказувати довільну адресу, у тому разі система буде підставляти й повертатимуть як адресу розділеної пам’яті певні адреси, звернення яких створюватиме явно помилкову ситуацію, виникне переривання процесу, під час яких система подивиться — хто й чому було ініціатором некоректного звернення до пам’яті, і що той процес має потрібні права доступу — система підставить потрібні адреси, інакше доступ для процесу буде заблокований. Це нагадує установку контрольної точки у програмі при налагодженні, коли створювали явно помилкова ситуація у тому, щоб було перервати процес і оцінити його состояние.

Третья функція — відкріплення поділюваної пам’яті: int shmdt (char *shmaddr); shmaddr — адресу прикріпленій до процесу пам’яті, який було отримано при підключенні пам’яті на початку работы.

Четвертая функція — управління поділюваної пам’яттю: int shmctl (int shmid, int cmd, struct shmid_ds *buf); shmid — ідентифікатор поділюваної пам’яті cmd — команда управления.

Зокрема, може бути команди: IPC_SET (змінити права доступу і власника ресурсу — цього потрібно мати ідентифікатор автора даного ресурсу чи суперкористувача), IPC_STAT (запросити стан ресурсу — в цьому випадку заповнюється інформація до структури, покажчик яку передається третім параметром, IPC_RMID (знищення ресурсу — по тому, як автор створив процес — з нею працюють процеси, які підключаються і відключаються, але з знищують ресурс, і з допомогою даної команди ми побачимо знищуємо ресурс в системе).

Усе це, стосовно функцій управління поділюваної памятью.

Передача сообщений.

[pic].

Наступним засобом взаємодії процесів у системі IPC — це передача повідомлень. Її суть наступного: у системі є так звана чергу повідомлень, у якій кожне повідомлення представляє з себе структуру даних, з якою асоційований буфер, у якому тіло повідомлення й ознака, що називається типом повідомлення. Черга повідомлень то, можливо розглянута подвійно: 1. чергу розглядається, як біжать єдина наскрізна чергу, порядок повідомлень у якій визначається хронологією їхнього попадання у цю чергу. 2. ще, оскільки кожне повідомлення має тип (на схемою — літера поруч із номером повідомлення), то цю чергу так можна трактувати, як суперпозицію черг, пов’язану з повідомленнями одного типа.

Система IPC дозволяє створювати поділюваний ресурс, званий «чергу повідомлень» — таких черг то, можливо довільне кількість. По аналогії з поділюваної пам’яттю — ми можемо створити чергу, підключитися до ній, послати повідомлення, прийняти повідомлення, знищити чергу, й т.д. Розглянемо функції роботи з чергами сообщений:

Створення черги повідомлень: int msgget (key_t key, int flags);

Залежно від прапорів при зверненні до цієї функції або створюється поділюваний ресурс, або здійснюється підключення до существующему.

Відправлення повідомлення: int msgsnd (int id, struct msgbuf *buf, int size, int flags); id — ідентифікатор черги повідомлення; struct msgbuf { long type; /* тип повідомлення */ char mtext[s] /* покажчик на тіло повідомлення */.

} size — розмір повідомлення, тут вказується розмір повідомлення, розміщеного по покажчику buf; flags — прапори, зокрема, прапором то, можливо константа IPC_NOWAIT.

За наявності такого прапора будуть такі дії - не виключено, коли буфера, передбачені системою під чергу повідомлень, переповнені. І тут можливі два варіанта — процес чекатиме звільнення простору, а то й зазначено IPC_NOWAIT, або функція поверне -1 (з певним кодом в errno), якщо було указано.

IPC_NOWAIT.

Прийом повідомлення: int msgrcv (int id, struct msgbuf *buf, int size, long type, int flags); id — ідентифікатор черги; buf — покажчик на буфер, куди приймуть повідомлення; size — розмір буфера, у якому розміщено тіло повідомлення; type — якщо тип нульовий, він ухвалено перше повідомлення з наскрізний черги, якщо тип більше нуля, то такому разі ухвалено перше повідомлення з черги повідомлень, що з типом, рівним значенням цього параметра. flags — прапори, зокрема, IPC_NOWAIT, він забезпечить роботу запиту без очікування приходу повідомлення, якщо сполучення момент звернення функції до ресурсу був, інакше процес буде ждать.

Управління чергою: int msgctl (int id, int cmd, struct msgid_dl *buf); id — ідентифікатор черги; cmd — команда управління, нам інтерес представляє IPC_RMID, яка знищить ресурс. buf — цей параметр опиниться без комментария.

Ми описали два кошти взаємодії між процесами. Що ми побачили? Зрозуміло, що назви й описи інтерфейсів мало зрозумілі. Перш всього слід зазначити те що як лише ми переходимо стосовно питання про взаємодії процесів, ми виникають проблеми синхронізації. І тут ми бачимо проблеми, пов’язані про те, що опісля, як ми попрацювали з поділюваної пам’яттю чи чергою повідомлень, у системі може бути «мотлох», наприклад, процеси, що у повідомлень, які у свою черга були. Тож якщо ми звернулися до функції отримання повідомлень з типом, що не прийшло, і а то й стоїть ключ IPC_NOWAIT, то процес чекатиме його, доки зникне ресурс. Або ж ми можемо забути знищити ресурс (і системи нікого не поправить) — цей ресурс залишиться у вигляді забруднюючої елемента системы.

Коли людина починає працювати з цими засобами, він бере себе відповідальність на наслідки, які можуть виникнути. Це набір проблем — системна синхронізація і акуратність. Друга проблема — синхронізація даних, коли приймач і передавач працюють одночасно. Зауважимо, що поганий по синхронізації ресурс з розглянутих нами — розділюваний пам’ять. Це означає, що коректна роботу з поділюваної пам’яттю неспроможна здійснюватися без використання коштів синхронізації, і зокрема, деяким елементом синхронізації то, можливо чергу повідомлень. Наприклад, ми можемо записати на згадку про дані і послати повідомлення приймачу, що вступила у ресурс, після чого приймач, отримавши повідомлення, починає зчитувати дані. Також у ролі синхронизирующего кошти можна застосовувати сигналы.

І це головне — не мову інтерфейсів, а проблеми, що потенційно можуть виникнути при взаємодії паралельних процессов.

Лекція № 18.

До сьогоднішнього дня ми розібрали два механізму взаємодії процесів у системі IPC — це механізм загальної (чи поділюваної) пам’яті і механізм повідомлень. Ми із Вами з’ясували, що з основних проблем, виникає при взаємодії процесів, є проблема синхронізації. Яскравим прикладом механізму, котрій цю проблему є найгострішою, є механізм взаємодії процесів з допомогою поділюваної памяти.

Ви ще пам’ятаєте, що механізм поділюваної пам’яті дозволяє створювати об'єкт, що стає доступним всім процесам, яким підтвердили ключ доступу до цього об'єкта, і навіть мають відповідні права. Після цього загальна пам’ять стає, з погляду кожного з цих процесів, хіба що фрагментом адресного простору кожного їх, якого той процес може добиратися через покажчик цього адресного простору. З іншого боку немає жодних коштів, яка б синхронизовать читання і запис у цю область даних. Позаяк у цю галузь даних одночасно має доступ довільне кількість процесів, то проблема синхронізації тут відтворена быть.

Можлива ситуація, коли один процесів почав запис в поділювану пам’ять, але ще закінчив, але інший процес що недочекався завершення записи, вважав нервовохворою і почав користуватися цією інформацією. І тут можливі колізії. Тобто. без синхронізації використовувати механізм поділюваної пам’яті невозможно.

Наступний механізм, який ми із Вами розглянули — чергу повідомлень. Є можливість спільної з поділюваним об'єктом, який називається чергу повідомлень. Є повідомлення, яке з деякого специфікатора типу, і деякого набору даних. Процес, підтвердивши ключ і права доступу до цього разделяемому ресурсу, може здійснювати дії з записи повідомлень у чергу, і з читання повідомлень з очереди.

Порядок читання і запис повідомлень з черги відповідає назві цієї структури — чергу. З іншого боку, завдяки тому, що кожен повідомлення типизировано, є можливість розгляду цієї черги з кількох точок зору. Перша думка — це одна чергу, й лад у ній хронологічний. Друга думка — це можливість уявлення цієї черги, у вигляді кількох черг, кожна з яких містить елементи певного типа.

Зрозуміло, що механізм повідомлень може у двох ролях: як засіб передача даних, і як засіб синхронізації (зрозуміло яким образом).

Отже, на сьогодні ми з двома цими механізмами. Нагадаю, як ми переходимо на роботу від однопроцессной завдання до завданню многопроцессной, ми відразу ж потрапляє й виникають проблеми, пов’язані про те, що будь-який паралелізм накладає певну відповідальність на програму. Це відповідальність по синхронізації доступу до поділюваної пам’яті, відповідальність за правильність підпрограми, що займається прийомом і передачею повідомлень тощо. Можна, наприклад, помилитися у механізмі передачі і прийому повідомлень завдяки тому, що якийсь процес буде нескінченно довго очікувати неіснуюче повідомлення, то, що ніколи у черзі не з’явиться, і системи вам ніколи таку помилку не зафіксує. Тобто. можливі зависання процесів, можуть утворитися незвільнені ресурси («сміття »), і усе веде до деградації системы.

Сьогодні ми напишемо таку програму: перший процес читатиме деяку текстову рядок із стандартного введення у разі, якщо рядок починається з літери «a », ця рядок як повідомлення передадуть процесу Якщо ж «b «- процесу У, якщо «q «- то процесам Проте й У і далі буде реалізовано вихід. Процеси Проте й У роздруковують отримані рядки на стандартний вывод.

Основной процес #include #include #include #include struct { long mtype; /* тип повідомлення */ char Data[256]; /* повідомлення */.

} Message;

int main () { key_t key; int msgid; char str[256]; key=ftok («/usr/mash », «p.s »); /*отримуємо унікальний ключ, однозначно визначальний доступом до ресурсу такого типу */ msgid=msgget (key, 0666 | IPC_CREAT); /*створюємо чергу повідомлень, 0666 визначає права доступу */ for (;;) { /* запускаємо вічний цикл */ gets (str); /* читаємо з стандартного введення рядок */ strcpy (Message.Data, str); /* і копіюємо їх у буфер повідомлення */ switch (str[0]){ case «a »: case «A »: Message. mtype=1; /* встановлюємо тип і посилаємо повідомлення чергу*/ msgsnd (msgid, (struct msgbuf*) (&Message), strlen (str)+1, 0); break; case «b »: case «B »: Message. mtype=2; msgsnd (msgid, (struct msgbuf*) (&Message), strlen (str)+1, 0); break; case q ": case «Q »: Message. mtype=1; msgsnd (msgid, (struct msgbuf*) (&Message), strlen (str)+1, 0);

Message.mtype=2; msgsnd (msgid, (struct msgbuf*) (&Message), strlen (str)+1, 0); sleep (10); /* чекаємо отримання повідомлень процесами Проте й У */ msgctl (msgid, IPC_RMID, NULL); /* знищуємо чергу*/ exit (0); default: break;

} } } Процесс-приемник, А /* процес У аналогічний з точністю до четвертого параметра в msgrcv */ #include #include #include #include struct { long mtype; char Data[256];

} Message;

int main () { key_t key; int msgid; key=ftok («/usr/mash », «p.s »); /* отримуємо ключ за тими самими параметрами */ msgid=msgget (key, 0666 | IPC_CREAT); /*створюємо чергу повідомлень */ for (;;) { /* запускаємо вічний цикл */ msgrcv (msgid, (struct msgbuf*) (&Message), 256, 1, 0); /* читаємо повідомлення з типом 1*/ if (Message.Data[0]= «q «|| Message. Data[0]= «Q ») break; printf («%p.s », Message. Data); } exit (0); }.

Семафоры.

З погляду тих проблем, з якими ми знайомимося, семафори — це є зовсім законні і існуюче поняття. Вперше ввів це поняття досить відомий український вчений Дейкстра. Семафор — це певний об'єкт, який має целочисленное значення P. S, і з яким пов’язані дві операції: V (S) і P (S).

Операція P (S) зменшує значення семафори на 1, і якщо S (0 процес продовжує роботу. Якщо S0, то процес продовжує виконання. Якщо S (0, то розблокується одне із процесів, котрий очікує у черзі процесів, що з семафором P. S, і поточний процес продовжить выполнение.

Вважається, що операції P (S) і V (S) неподільні. Це означає, що виконання операцій неспроможна зійти нанівець до їх завершення. Тобто. якщо семафор реалізований у системі, це мусить бути одна команда.

Приватним випадком продекларованої семафори є двоїчний семафор, максимальне значення одно одиничці. У цьому значення P. S то, можливо одно 1, це, що жодного з процесів (що з цим семафором) не в критичному ділянці. При S=0 одне із процесів перебуває у критичному ділянці {ось-ось потрапить у чергу}, а інший нормально функціонує. При P. S= -1 одне із процесів перебуває у критичному ділянці, а інший заблокований і що перебуває у очереди.

Насправді двоичные семафори найчастіше знаходили використання у апаратних реалізаціях, наприклад, в многомашинных комплексах із загальною оперативної памятью.

Однією з поділюваних ресурсів, що підтримує система IPC є т.зв. масив семафорів. Система дозволяє процесам, бере участь у взаємодії з цим поділюваним ресурсом, збільшувати чи зменшувати чи кілька семафорів з цього масиву на довільне значення (в межах розрядної сітки). Система забезпечує очікування процесами скасування однієї чи кількох семафоров.

Давайте розглянемо кошти, надані системою IPC, для створення, управління і взаємодії з семафорами.

int semget (key_t key, int n, int flags); int semop (int semid, struct sembuf * sops, int n);

struct sembuf{ short sem_num; /* номер семафори в масиві семафорів */ short sem_op; /* код операції, і треба виконати */ short sem_flg; /* прапори */.

}.

Перший параметр функції semget — ключ, другий — кількість семафорів (довжина масиву семафорів) та третій параметр — прапори. Через прапори можна визначити права доступу й ті операції, які мають виконуватися (відкриття семафори, перевірка, тощо.). Функція semget повертає целочисленный ідентифікатор створеного яке поділяється ресурсу, або -1, якщо ресурс — не удалося створити (причина — в errno).

Перший параметр функції semop — ідентифікатор семафори, другий — покажчик на структуру sembuf та третій параметр — кількість покажчиків на цей дивний організм, що передаються функцією semop. У структурі міститься всю інформацію про необхідному действии.

Поле операції інтерпретується так. Нехай значення семафори з номером sem_num одно sem_val. І тут, якщо значення операції не одно нулю, то оцінюється значення суми (sem_val + sem_op). Якщо це сума більше або дорівнює нулю, ті значення даного семафори встановлюється рівним сумі попереднього значення й коду операції. Якщо це сума менше нуля, то дію процесу буде призупинено до однієї з наступних событий:

1. Значення суми (sem_val + sem_op) стане більше або одно нулю.

2. Прийшов якийсь сигнал. (Значення semop у разі буде равно.

— 1).

Если код операції semop нульовий, то процес чекатиме скасування семафори. Якщо ми звернулися до функції semop із нульовим кодом операції, а до цьому моменту значення семафори досяг нулю, то ніякого очікування не происходит.

Розглянемо третій параметр — прапори. Якщо третій параметр нульовий, це означатиме, що прапори не використовуються. Прапорів є велика кількість зокрема. IPC_NOWAIT (у своїй прапорі в усіх отих випадках, ми казали, що процес чекатиме, він не ожидать).

Звертаю вашу увагу, що з звернення до функції semop можна передати n структур і виконати дії з n семафорами з цього масиву. Якщо у цій послідовності будуть присутні дві різних операції з одні семафором, то швидше за все, виконане буде последняя.

Функция управління масивом семафоров.

int semctl (int id, int sem_num, int cmd, union sem_buf arg);

Перший параметр — ідентифікатор, другий — номер семафори в масиві, з яких ми виконуватимемо команду cmd з третього параметра. Останній параметр — деяке об'єднання типу sembuf.

Команди може бути традиційні (IPC_RMID), та, крім нього є інші команди, у тому числі IPC_SET, що встановлює значення семафори, при цьому значення передається через об'єднання arg. При установці семафори цієї функцією, затримок, які визначають основний сенс роботи семафори, не будет.

Ось ті функції, призначених до роботи з семафорами. Приклад роботи з семафорами розглянемо ось на наступній лекции.

Лекція № 19.

Ми зупинилися на засобах синхронізації доступу до поділюваним ресурсів — на семафорах. Ми у тому, що семафори — що це формалізм, що завжди було запропоновано вченим у області комп’ютерних наук Дейкстрой, тому часто у літературі їх називають семафорами Дейкстры. Семафор — це є певна змінна та контроль ній визначено операції P і V. Одна дозволяє збільшувати значення семафори, інша — зменшувати. Причому з цим пов’язані можливості блокування процесу разблокировки процесу. Зазначимо, йдеться про неразделяемых операціях, то є операціях, які може бути перервані, якщо почалися. Тобто може бути те щоб під час виконання P чи V прийшло переривання, і система передала управління іншому процесу. Це — принципово. Тому семафори можна реалізовувати програмно, та заодно ми повинні розуміти, що ця реалізація ні коректна, так как.

1) програма пишеться людиною, а переривається апаратурою, звідси можливо порушення неразделяемости;

2) в розвинених обчислювальних системах, які підтримують многопроцессорную обробку чи обробку поділюваних ресурсів у однієї процесу, передбачені семафорные команди, які реалізовують операції P і V. Це важно.

Ми про реалізацію семафорів в Unix у системі IPC про те, що цю систему дозволяє створити поділюваний ресурс «масив семафорів», відповідно, як і до будь-якого разделяемому ресурсу, до цього масиву може забезпечений доступ від різноманітних процесів, які мають потрібними правами ключ до цього ресурсу.

Кожен елемент масиву — семафор. Для управління роботою семафори є функции:

A. semop, що дозволяє реалізовувати операції P і V над однією або кількома семафорами;

B. segctl — управління ресурсом. Під управлінням треба розуміти три вещи:

1. — отримання інформації про стан семафора;

2. — можливість створення деякого режиму роботи семафори, знищення семафора;

3. — зміна значення семафори (під зміною значення треба розуміти встановлення початкових значень, щоб залучити до подальшому семафори, як семафори, а чи не шухлядки передачі значень, інші зміни — лише за допомогою semop);

Давайте наведемо приклад, яким спробуємо проілюструвати використання семафорів на практике.

Наша програма буде оперувати з поділюваної памятью.

1 процес — створює ресурси «розділюваний пам’ять» і «семафори», далі він починає приймати рядки зі стандартного введення і записує в поділювану память.

2 процес — читає рядки поділюваної памяти.

Отже маємо критичний ділянку у момент, коли той процес ще дописав рядок, а інший її вже читає. Тому треба встановити деякі синхронізації і задержки.

Слід зазначити, що, як і всі програми, які ми наводимо, ця програма не досконалий. Не тому що ми поспіль не можемо її написати (в у крайньому випадку можна попросити своїх аспірантів або студентів), тому, що досконала програма займатиме занадто велике місце, і ми свідомо робимо деякі спрощення. Про ці упрощениях ми постараємося упоминать.

1й процес: #include #include #include #include.

int main (void) { key_t key; int semid, shmid; struct sembuf sops; char *shmaddr; char str[256]; key = ftok («/usr/mash/exmpl»,'S'); /* створюємо унікальний ключ */ semid = semget (key, 1,0666 | IPC_CREAT); /* створюємо один семафор з певними правами доступу */ shmid = shmget (key, 256, 0666 | IPC_CREAT); /*створюємо поділювану пам’ять на 256 елементів */ shmaddr = shmat (shmid, NULL, 0); /* підключаємося до поділу пам’яті, в shaddr — покажчик на буфер з поділюваної пам’яттю*/ semctl (semid, 0, IPC_SET, (union semun) 0); /*инициализируем семафор зі значенням 0 */ sops. sem_num = 0; sops. sem_flg = 0;

/* запуск нескінченного циклу */ while (1) { printf («Введите рядок:»); if ((str = gets (str)) == NULL) break; sops. sem_op=0; /* очікування скасування семафори */ semop (semid, &sops, 1); strcpy (shmaddr, str); /* копіюємо рядок в разд. пам’ять */ sops. sem_op=3; /* збільшення семафори на 3 */ semop (semid, &sops, 1);

}.

shmaddr[0]='Q'; /* зазначимо 2ому процесу те що, */ sops. sem_op=3; /* що час завершуватися */ semop (semid, &sops, 1); sops. sem_op = 0; /* чекаємо, поки обнулится семафор */ semop (semid, &sops, 1); shmdt (shmaddr); /* отключаемся від разд. пам’яті */ semctl (semid, 0, IPC_RMID, (union semun) 0); /* вбиваємо семафор */ shmctl (shmid, IPC_RMID, NULL); /* знищуємо поділювану пам’ять */ exit (0); }.

2й процесс:

/* тут треба коректно визначити існування ресурсу, якщо є - підключитися, якщо ні - зробити ще щось, але держава саме цього ми робити думати */ #include #include #include #include.

int main (void) { key_t key; int semid; struct sembuf sops; char *shmaddr; char st=0;

/* далі аналогічно попередньому процесу — ініціалізації ресурсів */ semid = semget (key, 1,0666 | IPC_CREAT); shmid = shmget (key, 256, 0666 | IPC_CREAT); shmaddr = shmat (shmid, NULL, 0); sops. sem_num = 0; sops. sem_flg = 0;

/* запускаємо цикл */ while (st≠'Q') { printf («Ждем відкриття семафори n»);

/* очікування позитивного значення семафори */ sops. sem_op=-2; semop (semid, &sops, 1);

/* очікуватимемо, поки «значення семафора"+"значение sem_op» не понад 0, тобто якщо «3», то «3−2=1» */.

/* тепер значення семафори одно 1 */ st = shmaddr[0];

{ /*критична секція — роботу з поділюваної пам’яттю — на той час перший процес до поділюваної пам’яті доступу не имеет*/}.

/*після роботи — закриємо семафор*/ sem. sem_op=-1; semop (semid, &sops, 1);

/* повернувшись у початок циклу ми знову чекатимемо, поки значення семафори не стане більше нуля */ } shmdt (shmaddr); /* звільняємо поділювану пам’ять і виходимо */ exit (0); }.

Це програма, що складається з двох процесів, одночасно які працюють із поділюваної пам’яттю. Зрозуміло, що за наявності інтересу можна працювати з сообщениями.

У цьому ми закінчуємо велику підтримку і досить важливу тему організації взаємодії процесів в системе.

Наша самоціль — не вивчення тих засобів, що надає Unix, а вивчення принципів, що надає система на вирішення розв’язання тих чи інших завдань, бо інші ОС надають аналогічні чи схожі засоби управління процессами.

Системи программирования.

Система програмування — це комплекс програмних засобів, які забезпечують підтримку технологій проектування, кодування, тестування і налагодження, називається системою программирования.

Етап проектирования.

Було сказано, що у сьогодні дуже складно, а практично неможливо створювати програмне забезпечення без етапу проектування, такої ж довгого, нудного і детального періоду, який проходить під час проектування будь-якого технічного об'єкта. Слід зрозуміти, що програми, що пишуться студентами як практичних і дипломних завдань є щодо справи програмами — це іграшки, бо їх складність невелика, обсяги незначні і такі програми можна писати злегка. Реальні самі програми так і не створюються, так ж, як і створюються складні технічні об'єкти. Ніхто будь-коли може собі уявити, щоб якась авіаційна компанія продекларувала створення нової літака і подала команду своїм заводам зліпити лайнер з такими-то параметрами. Так немає. Кожен із елементів такого об'єкта, як літак, проходить складний етап проектирования.

Наприклад, фірма Боїнг підняла у повітря літак «Боинг-777», замечательность цього факту у тому, що літак злетів без попередньої продувки в аеродинамічній трубі. Це означає, що все літак спроектували і промоделирован на програмних моделях, і це проектування моделювання була настільки чітким і правильним, що дозволило відразу ж потрапити підняти у повітря. Довідково — продування літака на аеродинамічній трубі стоїть божевільні деньги.

Приблизно те ж саме відбувається за створенні складних сучасних програмних систем. На початку 80-х рр розпочато СОІ (стратегічна оборонна ініціатива), її ідея був у тому, щоб зробити складної технічної системи, яка у автоматичному режимі встановила контроль за пусковими установками СРСР та Варшавського блоку, у разі фіксації старту з наших позицій якогось непродекларированного об'єкта автоматично починалася війна. Тобто запускалися кошти знищення даного об'єкту і кошти на дій у відповідь. Реально той департамент Збройних Сил, яка займалася цим проектом, відчув ряд криз в зв’язку з, провідні фахівці з галузі програмного забезпечення відмовлялися брати участь у реалізації проекту через неможливість коректно його спроектувати, оскільки система мала гігантським потоком вхідних даних, основі яких повинні бути прийнято однозначні рішення, відповідальність які оцінити дуже важко. На насправді цю проблему підштовхнула до розвитку з одного боку — мов програмування, які мали надійністю, зокрема, мову Ада, одній з метою котрого треба було створення безпомилкового ПО. У цих мовами накладалися обмеження на місця, у найбільш ймовірне виникнення помилки (межмодульные інтерфейси; висловлювання, де є різні типи даних, і т.п.) Зауважимо, що мова З не відповідає вимогам безпеки. З іншого боку — до детальному проектування, який би дозволяло деяким формальним чином описувати створюваний проект і працювати на проект у частині його деталізації. Причому, перехід від деталізації до кодування у відсутності б чіткої кордону. Зрозуміло, що це є певна завдання сьогоднішнього, а перед завтрашнім днем, але реально розробники програм перебувають у шляху створення засобів, яка б поєднати проектування кодування. Сьогоднішні системи програмування, які будуються на объектно-ориентированном підході, частково вирішують цю проблему.

Наступна проблема проектування. Ми продекларували модулі, оголосили їх взаємозв'язки, якось описали семантику модулів (це теж проблема). Але дасть гарантії, що це проект правильний. Аби вирішити цієї проблеми використовується моделювання програмних систем. Тобто, коли разом із побудовою проекту, який декларує все інтерфейси, функціональність та інші, ми можемо якимось чином промоделировать роботу всієї чи частин створюваної системи. Реально під час створення великих програмних систем нині немає єдиних інструментаріїв для таких дій. Кожні з систем мають різні підходи. Іноді ці підходи (як і ми, і там) досить архаичны.

Але тим щонайменше слід розуміти, що період проектування є дуже важливий момент.

Кодирование.

Якщо складено нормальний проект, те з кодуванням проблем немає. Але слід звернути увагу, що московський спеціаліст в програмуванні це той, хто швидко пише на З, а той, хто добре та детально зможе спроектувати завдання. При сучасному розвитку інструментальних коштів закодувати зможе будь-який школяр, а спроектувати систему — і є професійна завдання людей, котрі займаються програмуванням — вибрати інструментальні кошти, скласти проект, промоделировать решение.

Основний компонент системи кодування — мову програмування. У кожного програміста лежить ієрархія мов програмування — від машинного коду і ассемблера до універсальних мов програмування (FORTRAN, Algol, Pascal, З тощо.), спеціалізованих мов (SQL, HTML, Java і т.д.).

Ми маємо ЯП і програму, написану в нотації цієї мови. Система програмування забезпечує переклад вихідної програми в об'єктний мову. Цей процес відбувається перекладу називається трансляцією. Об'єктний мову може бути як деяким мовою програмування високого рівня (трансляція), і машинний мову (компіляція). Ми можемо казати про трансляторах-компиляторах і трансляторах-интерпретаторах.

Компілятор — це транслятор, переводить текст програми в машинний код.

Інтерпретатор — це транслятор, який звичайно поєднує процес перекладу і виконання програми (компілятор спочатку переводить програму, а лише для того яку можна виконати). Він, говорячи згрубша, виконує кожну рядок, у своїй машинний код не генерується, а відбувається звернення до деякою стандартної бібліотеці програм інтерпретатора. Якщо результат роботи компілятора — код програми на машинному мові, то результат роботи транслятора — послідовність інтерпретацій функцій інтерпретації. При цьому, як і при компіляції, коли створюється оттранслированная програма, нас також може бути створена програма, але нинішнього интепретируемом коді (послідовності інтерпретацій функцій интерпретации).

Зрозуміла різниця — компілятори ефективніші, позаяк у интерпретаторах неможлива оптимізація та постійні виклики функцій теж ефективні. Але інтерпретатори більш зручні завдяки тому, що з інтерпретації можливо включати у функції інтерпретації безліч сервісних коштів: налагодження, можливість інтеграції інтерпретатора і мовного редактора (компіляція це робити не позволяет).

Сьогодні кожен із методів — і компіляція і інтерпретація займають свої певні ниши.

Лекція № 20.

Минулої лекції ми розпочали розглядати системи програмування. На насправді цю тему є підставою цілого курсу, оскільки цю тему включає у собі усе те, може бути у сучасній науці про комп’ютерах — те й хороші практичні рішення, і розроблені, реально застосовувані, теоретичні рішення, й багато іншого. Ми, що систему програмування — це комплекс програм, який би життєвий цикл програми у системі. Життєвий цикл створюваного програмного забезпечення містить такі етапи: проектування кодування тестування отладка.

Ми із Вами наголошували на важливості етапу проектування, що програмний продукт представляє з себе дуже складний об'єкт, має величезну кількість перетинів поміж своїми компонентами. Пропустити етап проектування не можна. Для проектування програмних систем, необхідні спеціалізовані кошти, яка б (в ідеалі) описувати проект деяким формальним чином, і послідовно уточнюючи його, приводити формальне опис проекту на реальний код программы.

Ми, що важливим етапом проектування, є етап моделювання системи, тобто. той етап, ми беремо зовнішні навантаження, що потенційно можуть надходити на систему, приписуємо властивості потоку подій, пов’язаних із цими зовнішніми навантаженнями, певний статистичний закон, і розглядаємо можливе поведінка системи за такої эмуляции довкілля. Зрозуміло, що етапу моделювання також важко створити будь-якої програмний продукт.

Етап кодирования.

Ми також казали, що важливою частиною цьогорічного системи програмування є кошти кодування. Етап кодування в життєвому циклі програми традиційно (і звичайно неправильно) однозначно пов’язують із поняттям системи програмування. Дуже багато, коли починають говорити про систему програмування, розуміють під цим транслятор мови програмування. Хотів би цими лекціями вам показати, що систему програмування — це щось більш широке, ніж транслятор. Усі компоненти однаково необходимы.

Транслятор — це програма, яка переводить програму нотації однієї мови, в нотацію іншої мови. Компілятор — це транслятор, який переводить програму з нотації однієї мови в нотацію машинного мови. Машинним мовою може або код конкретної машини, або об'єктний код. Трансляторы може бути інтерпретаторами, тобто. поєднувати аналіз вихідної програми з його виконанням. Результатом роботи інтерпретатора не машинний код, а послідовність інтерпретацій бібліотеці функцій інтерпретатора. Інтерпретатор, на відміну транслятора, може вибирати одну по одній інструкцією, і відразу їх виконувати. При інтерпретації (на відміну від трансляції чи компіляції), можна починати виконання програми має синтаксичні ошибки.

Кросс-трансляторы. Коли дивитися на системи трансляції, тобто одна частка трансляторів — кросс-трансляторы (і кросс-компиляторы). Крос транслятор дбає про деякому типі обчислювальної системи, яка називається інструментальна ЕОМ. Інструментальна ЕОМ може характеризуватися своєї архітектурою і/або операційним оточенням, яке функціонує у ньому. Кросс-транслятор забезпечує переклад програми, записаній в нотації деякого мови, в код обчислювальної системи, відмінній від інструментальної ЕОМ. Та обчислювальна система, на яку генерується код, називається об'єктної ЕОМ, і, той код, який ми маємо, називається об'єктним кодом (це теж, що об'єктний модуль). Наприклад, комп’ютера, який управляє рухової установкою літака, не треба мати операційну середу, що забезпечить роботу користувача для розробки програм йому. Йому не треба мати кошти редагування тексту, трансляції тощо., тому що в неї лише функція — управляти рухової установкою. У цьому комп’ютері працюватиме операційна система реального часу. До сформування програм для що така комп’ютерів, і використовуються системи кроспрограмування і кросс-трансляторы. На звичайній машині типу PC то, можливо розміщений транслятор, який генерувати код для заданого комп’ютера. [pic].

Насправді, бувають ситуації, коли тип об'єктної машини збігаються з типом інструментальної машини, але відрізняються операційні середовища, які функціонують на даних машинах. І тут також потрібна система кроспрограммирования.

Кросс-трансляторы також потрібні розробникам нових автомобілів, які хочуть паралельно з її появою створити програмне забезпечення, що буде працювати в цій машине.

Обробка модульної програми. З погляду етапу кодування можна розглянути послідовність обробки програми більш крупноблочно, ніж з погляду трансляції. Ми із Вами говорили на початкових лекціях у тому що мови програмування підтримують модульність (програма представляється як групи модулів і взаємозв'язок між тими модулями здійснюється з допомогою відповідних оголошень у яких). Давайте подивимося, що відбувається на етапі обробки програми, написаної однією з модульних мов. [pic].

Нехай є певна група модулів і відповідні цим модулями тексти програм, мовами, що використовуються програмування. Мовними засобами визначено зв’язок між модулями.

Перший етап, що відбувається — це етап трансляції (або компіляції) кожного з модулів. Після трансляції модуля як вихідного тексту ми маємо об'єктний модуль — це є машинно-ориентированное уявлення програми, у якому присутні фрагменти програми в машинному коді, і навіть інформація про необхідних зовнішніх зв’язках (посилання об'єкти у інших модулях). Інформації про необхідних зовнішніх зв’язках (крім інформації про місцезнаходження зовнішніх об'єктів) також включає у собі посилання тих місця машинного коду, які намагаються використати адреси зовнішніх об'єктів, тобто. тих недоопрацьовані команди, які можна обробити зза те, що при трансляції модуля не відомо де які об'єкти перебувають. Тобто. об'єктний модуль — це машинне уявлення програмного коду, де ще не дозволені зовнішні зв’язку. Об'єктний модуль може утримувати додаткову інформацію (наприклад, інформацію, необхідну налагодження — таблиці імен та т.д.).

До кожного із вихідних модулів ми матимемо об'єктний модуль. Після цього є всі об'єктні модулі, що є нашу програму, і навіть модулі необхідних бібліотек функцій, надходять на вхід редактору зовнішніх зв’язків. Редактор зовнішніх економічних зв’язків моделює розміщення об'єктних модулів в оперативної пам’яті дозволяє всі системи зв’язку з-поміж них. У результаті ми маємо виконуваний модуль, що може бути запущено як процес. Іноді трансляторы як результату трансляції видають модуль на ассемблері відповідної машины.

У цю схему також часто додається етап оптимізації програми, причому оптимізація може статися до етапу трансляції (тобто. в термінах вихідного мови) або/та в після трансляції (в термінах машинного коду). Наприклад до трансляції можна визначити все константні подвыражения тощо. Для машин типу PC етап оптимізації може бути такий важливий, оскільки це запитання зазвичай дозволяється купівлею якогось швидшого компонента, але є клас машин (mainframe), котрим цей етап необходим.

Погляньмо на цю проблему кодування з іншого боку. Ми подивимося як влаштований етап трансляции.

Кожен транслятор при обробці програми виконує такі действия.

I. Лексичний анализ.

II. Синтаксичний анализ.

III. Семантичний аналіз стану і генерація кода.

Лексичний аналіз. Лексичний аналізатор виробляє аналіз вихідного тексту щодо правильності записи лексичних одиниць вхідного мови. Потім він переводить програму з нотації вихідного тексту в нотацію лексем.

Лексичні одиниці - це мінімальні конструкції, які можна продекларовані мовою. До лексичним одиницям ставляться: ідентифікатори ключове слово код операції роздільники константы.

Речові константи у деяких трансляторах можуть представлятися в вигляді групи лексичних одиниць, кожна з яких є целочисленной константой.

Після цього вихідна програма перетворюється на вид лексем. Лексема — це деяка конструкція, що містить дві значення — тип лексеми і номер лексемы.

|Тип лексеми |№ лексеми |.

Тип лексеми — це код, який свідчить у тому, що це лексема належить одній з позначених нами груп. приміром лексема то, можливо ключовим словом, тоді полі типу стоятиме відповідний номер. Номер лексеми уточнює конкретне значення цієї лексеми. Якщо, приміром, було ключовим словом begin, то номер лексеми міститиме число, відповідне ключового слову begin. Якщо тип лексеми — ідентифікатор, то номер лексеми буде номером ідентифікатора в таблиці імен яку створить лексичний аналізатор. Якщо тип лексеми — константа, то номер лексеми теж буде посиланням на таблицю з константами.

Після лексичного аналізатора ми маємо компактну програму, в якого немає вже зайвого (прогалин, коментарів, тощо.). Уся програма складена як таких лексем, і тому більше компактна і проста.

Синтаксичний аналіз. Програма як лексем надходить на вхід синтаксичному аналізатору, що здійснює перевірку програми на предмет правильності з погляду синтаксичних правил. Результатом роботи синтаксичного аналізатора є або з’явилася інформація, що у програмі є синтаксичні помилки і вказівку координат цих помилок, і їх діагностика, або уявлення програми у певній проміжному вигляді. Цим проміжним виглядом то, можливо, припустимо, бесскобочная запис, або запис як дерев (хоча одне однозначно зводиться до іншому). Це проміжне уявлення, що є синтаксично і лексично правильної програмою, надходить на вхід семантичному анализатору.

Семантичний аналіз. Семантика — усе це те що описується синтаксисом і лексикою мови. Приміром, лексикою і синтаксисом мови складно описати те, що не те передавати управління тіло циклу не через початок циклу. Виявлення таких помилок — одне з функцій семантичного аналізу. у своїй семантичний аналізатор ставить за відповідність синтаксично і семантично правильним конструкціям об'єктний код, тобто. відбувається генерація кода.

Система програмування і трансляції - дуже наукомістка область програмного забезпечення. Організація трансляторів — це перша застосування теоретичних досягнень науки, які полягали у наступному. за рахунок можливості використання тих чи інших граматик (наборів формальних правил побудови лексичних конструкцій і синтаксичних правил), можна розділити програмну реалізацію лексичних і синтаксичних аналізаторів на два компонента. Перший компонент — це програма, що у загальному разі, нічого не знає у тому мові, і його буде аналізувати. Другий компонент — це набір даних, що становить з себе формальне опис властивостей мови, який ми аналізуємо. Поєднання цих двох компонентів, дозволяє автоматизувати процес побудови лексичних і синтаксичних аналізаторів, і навіть генераторів коду, для різних мов програмування. Сучасні системи програмування в собі мають кошти автоматизації побудови компіляторів. Для ОС UNIX є пакет LEX — пакет генерації лексичних аналізаторів, це і є пакет YACC — для генерації синтаксичних аналізаторів. Усе це досягається з допомогою можливості формалізації властивостей мови, і видів використання цього формального описи, як параметрів тих чи інших інструментальних средств.

Проходи трансляторів. Ми із Вами розглянули транслятор з місця зору функціональних етапів. Але найчастіше ми чуємо про однопроходных трансляторах, двухпроходных, трехпроходных, тощо. З проблемою трансляції пов’язано поняття «прохід ». Прохід — це повний перегляд деякого уявлення вихідного тексту программы.

Є трансляторы однопрохідні. Це означає, що транслятор переглядає вихідний текст від початку остаточно, і до кінця перегляду (в разі правильності програми) то здобуває об'єктний модуль.

Якщо ми подивимося Сі-компілятор, з що ви працюєте, то скоріш всього він двухпроходный. Перший прохід — це робота препроцесора. Після першого проходу з’являється чиста Сі-програма без будь-яких препроцессорных команд. На Другому проході відбувається лексичний, синтаксичний і семантичний аналіз, і врешті-решт у вас з’являється об'єктну програму вигляді ассемблера.

Кількість проходів у деяких трансляторах пов’язані з кількістю етапів, тобто. бувають реалізації, котрим зручно зробити окремий прохід для лексичного аналізу, окремий прохід для синтаксичного аналізу та окремий прохід для семантичного аналізу. Якщо транслятор многопроходный, виникає проблема збереження проміжної нотації програми між проходами.

Make-файл. До тієї ж проблемі кодування належить засіб підтримки розробки програмних проектів. Однією з популярних коштів, орієнтованих роботу однієї чи кількох програмістів, є т.зв. make-средство. Назва походить від відповідної команди ОС UNIX. З make-командой пов’язаний т.зв. make-файл, у якому через підрядник вказуються взаємозв'язку різноманітних файлів, одержуваних при трансляції, редагуванні зв’язків, тощо., й ті дії, що треба виконати, коли ці взаємозв'язку порушуються. Зокрема можна сказати, що деякий виконуваний файл залежить від групи об'єктних файлів, і Якщо ця зв’язок порушена, треба виконати команду редагування зв’язків (link …). Що означає порушення залежності І що отже зв’язок? Make-команда перевіряє існування цих об'єктних файлів. Якщо вони самі існують, то часи їх створення повинні прагнути бути попередні, ніж час створення виконуваного файла. У разі, якщо це правило порушено (але це перевіряє make-команда), він запущено редактор зв’язків (link), який наново створить виконуваний файл. Тим самим було такий засіб дозволяє нам працювати з програмою, що з великого кількості модулів, і піклуватися про те, чи в момент часу виконуваний файл набору об'єктних файлів або відповідає (можна просто запустити make-файл).

Make-файлы можуть утримувати дуже багато що така рядків, які в такий спосіб пов’яжуть як об'єктні і виконувані файли, а й кожен із вихідних файлів з певним об'єктним файлом, тощо. Тобто. суть така, що тепер після роботи треба щоразу кожному за файла запускати компілятор, редактор зв’язків, а можна просто запустити make-файл, і сам визначає також і вибере ті файли, потрібно коригувати, і виконає необхідне. Насправді такі кошти зараз мають майже всі системи программирования.

Система контролю версій. Якщо make-файл — це система, призначена на одне програміста, у разі, для кількох програмістів, то якщо в нас існує великий колектив, що робить великий програмний проект, то використовується т.зв. контроль версій, що дозволяє організовувати коректну роботу великих колективів людей над у тому ж проектом, засновану спроможності декларації версій і здійсненні контролю над цими версиями.

Етапи тестування і отладки.

Тестування — це пошук ситуації, у якій програмний продукт не працює. У цьому використовуються набори тестів, визначальних зовнішню навантаження на програмний продукт. Можна сміливо сказати, що ваша програма оттестирована певному наборі тестів. Твердження, що ваша програма оттестирована загалом у загальному разі некорректно.

Налагодження — це процес пошуку, локалізації і виправлення помилки. Налагодження здійснюється, ми маємо програмну систему, і Бог знаємо, що вона дбає про якомусь із тестов.

Проблеми тестування і налагодження — це є проблеми крайньої важливості. За оцінками, на тестування і налагодження витрачається порядку 30% часу розробки проекту. Складність тестування і налагодження залежить від якості проектування й кодування. Тестування найчастіше виконати складно і часто для тестування використовуються модельні навантаження, наприклад ми тестуємо бортову мережу літака, щось зможемо зробити землі, щоте або інакше робиться вже в реальному польоті, коли збираються дані і фіксується працює система або работает.

Лекція № 21.

Тема, що з вами почнемо розглядати буде короткій та простий, і ми позначимо основні болючі місця. Деталі й подробиці ви повинні вивчити сами.

Командний мову ОС UNIX CSHELL (CSH).

Багатьом користувачів програмного забезпечення основним і єдиним властивістю, яким звертає увагу користувач, є не внутрішній лад системи, а той інтерфейс, які даються системою користувачеві. Майже кожен система має кошти інтерактивного взаємодії з користувачем, тобто. кошти, що дозволяють у тому чи іншій формі вводити запити виконання дій. З цього погляду UNIX підтримує можливість роботи з довільним кількістю інтерпретаторів команд. У файлі /etc/passwd/ одна з полів, які стосуються даному користувачеві, містить повне ім'я інтерпретатора команд, який має бути запущено перед входом користувача до системи. У випадку, перед входом користувача до системи то, можливо запущена абсолютно будь-яка программа.

Традиційними інтерпретаторами команд у системі UNIX є SH, CSH і BASH. Давайте розглянемо на концептуальному рівні що таке СSH (в принципі, всі інтерпретатори команд схожі один на одного й є деяким розширенням SH).

Інтерпретатор команд визначає структуру введеної команди. Команда (для CSH) — це послідовність символів, закінчується деяким кодом, і який складається з слів. Слова — це послідовності символів, які містять роздільники. Роздільники — це набір фіксованих символів, зокрема звичним нам роздільником є прогалину. Крім прогалини роздільниками служать коми, знаки < >, тощо. Кожен з цих роздільників має власну інтерпретацію. Зокрема, символ «| «означає створення конвеєра. Наприклад команда ls|more дасть можливість уникнути швидкий висновок тексту на екран і поза екран, і дозволить погортати его.

Система UNIX підтримує набір спеціальних символів, які називаються метасимволами. Метасимволы зазвичай зустрічаються за тими словами команди, і інтерпретуються за заздалегідь визначеними правилам. Метасимволов існує багато, зокрема у тому числі знайомі нам * і ?. Команда rm * віддалить все файли не які з точки нинішнього року каталозі.? означає, на місці цього символу може бути одна будь-який знак. Метасимволы можуть бути парними. Наприклад всередині квадратних скобок вказується альтернативна група, припустимо, [abc] означає, що замість цієї квадратної дужки може бути одна з вище перерахованих у ній символів (будь-яку цифру можна поставити так [0−9]).

CSH дозволяє об'єднувати команди. І тому також використовуються метасимволы. Якщо всередині круглих скобок перераховані деякі команди, то запустится іще одна інтерпретатор, який цю послідовність команд. Наприклад команда (cd /etc; lsla|grep pas) змінить каталог і здійснить пошук у тому каталозі рядки pas.

У чому відрізняється тим часом, виконалася ця команда в інтерпретаторі з яких ми працюємо, або якщо запущено іще одна інтерпретатор. Різниця те, що, у разі не зміниться поточний каталог, як і раніше, що виконалася команда зміни каталога.

Є можливість об'єднувати команди з допомогою {}. Усі команди, перелічені в фігурних дужках будуть запущені зліва-направо, але у своїй на стандартний висновок буде покладено об'єднана послідовність стандартних висновків всіх команд. {more t. b; more t. c}>tt.b — в файлі tt. b виявиться стандартний висновок однієї команди, та був стандартний висновок інший, ця команда без фігурних скобок помістила б туди стандартний висновок лише другою команды.

Інтерпретатор команд має набір вбудованих команд. Усі команди поділяються на два типа:

1. Команди, які реалізовані як окремих файлів. Це команди, які можна модифікувати чи додавати новые.

2. Команди, яке вмонтовані в інтерпретатор команд, тобто. ті команди, що виконує сам інтерпретатор. До таких командам належить команда kill, через яку здійснюється передача відповідного сигналу від імені інтерпретатора. Є й корисна команда alias, яку використовують перейменування існуючих команд.

Інтерпретатор команд CSH дозволяє здійснювати роботи з передісторією. Він може організувати буферизацію N останніх команд організовує доступом до списку останніх команд. Зокрема, можна виконувати і редагувати командні рядки списку передісторії і знову їх виконувати. CSH має можливість іменувати рядки списку передісторії. Посилання на відповідну рядок здійснюється з допомогою команди, яка починається з символу !, котрого супроводжує деяка суффиксная частина. Посилання !! виконує останню команду. Посилання виду!! N, де N — певна кількість, виконує рядок із з пищання передісторії з номером N. Якщо N негативно, то номер рядки відраховується з кінця, приміром, !!-1 означає виконання останньої команди. З іншого боку, може бути деякі контекстные посилання виду !.

Змінні CSH.

Інтерпретатор команд дає можливість програмування на рівні CSH. І тому передбачена декларація змінних і можливість привласнення ним значення, і навіть набір высокоуровневых операторів, які зі своєї семантикою нагадують оператори мови Сі (тому й назва інтерпретатора CSH). CSH фактично є высокоуровневый мову з операторами мови Сі. Оперуючи зі змінними CSH можна складати програми, які виконують деякі действия.

До того ж, є визначені імена, що відповідають за надстройку системи, зокрема, у тому, скільки рядків передісторії зберігаються. Збереження відбувається у двох іпостасях: перше — це оперативне збереження, є параметр (змінна history), який визначає, скільки рядків має бути збережено протягом останнього сеансу роботи. Друге — є можливість передісторії між сеансами, тобто. при черговому вході систему вже буде зовсім визначено певний список передісторії (розмір списку — в перемінної savehistory).

Крім змінних, з допомогою яких здійснюється настроювання, і імена яких визначено, є іще одна клас змінних CSH — це т.зв. внутрішні перемінні, що є зарезервованими. Це перемінні, які мають визначені імена визначають своє значення через внутрішні функції інтерпретатора команд. Зокрема, є змінна path, це є текстовий масив, де знаходяться текстові рядки, містять повні імена деяких каталогів. Відповідно до вмістом перемінної path, CSH здійснює пошук файлів, що є командами, уведеними користувачами. Ми із Вами казали, що в UNIX (крім вбудованих команд) спеціальних команд немає, командою є будь-який виконуваний файл. Якщо користувач ввів деяке ім'я NAME, пошук виконуваного файла безпосередньо з ім'ям NAME здійснюватиметься, по-перше, нинішнього року каталозі, тоді як у других, в каталогах, вказаних у перемінної path, в відповідному порядке.

Змінна home — містить ім'я домашнього каталога.

Змінна ignoreeof — це змінна, установка якої блокує завершення сеансу роботи з введення символу^D (Ctrl-D).

У системі можна варіювати вид запрошення (ввести в дію) з допомогою перемінної prompt, і запрошення може бути досить інтелектуальним. У ньому, наприклад, можуть бути дата і т.п.

Ми із Вами розглянули зміну path, вони можуть визначати багато директорій. Уявіть собі, що вводжу деяку командний рядок NAME і нинішнього року каталозі відповідного файла немає. Це означає, що здійснено пошук файла безпосередньо з ім'ям NAME за всі каталогам, записаним в перемінної path (з усіма наслідками). Це то, можливо довго. Якщо ж врахувати, що ви працюєте в многопользовательской системі, і кожен постійно вводить якісь команди, то накладні витрати виходять божевільними. Система UNIX розумна система, одним із правил, яких дотримувалися її розробники було те, що й десь щось оптимізувати, треба це. При вході користувача до системи на підставі значення перемінної path формується hash-таблица імен виконуваних файлів, що є в усіх названих каталогах (природно, враховується порядок каталогів). Пошук команди (якщо вона знайдено нинішнього року каталозі) полягатиме в перегляді цієї швидкої hashтаблиці. У результаті досягається прискорення доступу до команди, хоча за вході у систему можлива значна затримка, яка викликана формуванням цієї hash-таблицы.

Припустимо, користувач ввійшов у систему, і потім адміністратор додав команду, яка цьому користувачеві необхідна. Але завдяки тому, що hash-таблица вже сформувалася, доступом до ній (без набору повного імені) закритий, хоча він є в каталозі, зазначеній у path. І тут можна переформувати hash-таблицу з допомогою команди rehash.

Крім усіх цих змінних, CSH мають ще одну категорію змінних, які називаються перемінними оточення. Якщо ви і згадайте, то, при запуску процесу функції main передаються кілька параметрів, серед яких був масив значень змінних оточення. У процес можна передати ті параметри, які характеризують сеанс роботи користувача в момент часу. Зокрема можна передати ім'я домашнього каталогу, ім'я поточного каталогу, ім'я термінала, від якого викликаний цей процес і т.д.

CSH має можливість роботи зі змінними оточення (можна їх переглядати, встановлювати і т.п.).

З допомогою коштів CSH можна складати програми. У цих програмах можуть фігурувати імена змінних CSH, які ми можемо інтерпретувати як імена файлів. Засобами CSH можна визначати ряд властивостей, що з ім'ям, яку ми інтерпретуємо як ім'я файла. Зокрема, є можливості перевірки, може бути такий-то файл. Є можливість перевірки, чи є такий-то файл каталогом або є. Є можливість перевірки всіх прав доступу. Є можливість визначення розміру файла. І, нарешті, є можливість запуску файла як команди. До речі, з допомогою цих коштів реалізовано безліч команд системи. Програми на CSH можна вводити через підрядник, у разі CSH ж виконує функцію транслятора-интерпретатора, а можна програму на CSH записати в певний файл й виконувати його як командний файл (Але однаково відбуватиметься процес интерпретации).

Спеціальні файлы.

Будь-який командний мову має набір т.зв. профайлов, чи стартових файлів. CSH має чи два різновиди цих файлів: це файли, які можуть опинитися виконуватися при старті CSH, і файли, які виконуються при завершенні работы.

При старті CSH працює із двома файлами — .cshrc і .login. Файл. cshrc — це командний файл, у якому користувач на власний розсуд може розміщувати довільне кількість команд на CSH, які виконуватися відразу після запуску CSH (наприклад, у тому файлі може бути команда тестування файловою системи й т.п.). Файл. login запускається перед входом користувача до системи. У цьому вся файлі він може перебувати будь-яка послідовність команд, наприклад там то, можливо перевизначення імен команд, найбільш прийнятне для даного користувача (оскільки мнемоніка команд в UNIX досить важка, та й параметрів в кожній команди много).

При завершенні роботи з CSH запускається файл безпосередньо з ім'ям .logout в якому може бути певний набір команд.

Є стандартний файл, котрі можуть утворитися своєю практикою — це файл.history. Коли ви визначено можливість історії, то саме на цьому файлі буферизуется передісторія вашої работы.

Тепер підсумуємо, і це нагадаю у чому повинні розібратися сами:

1. CSH — як мову програмування. Типи змінних CSH.

Програмування на CSH.

1. Угоди, які визначає CSH під час роботи зі строками.

Розбивка командної рядки на свої слова. Інтерпретація метасимволов. Можливість посилання командні рядки предыстории.

2. Вбудовані команди CSH.

3. Спеціальні перемінні CSH: внутрішні перемінні і які змінюються окружения.

4. Спеціальні командні файли CSH.

Лекція № 22.

Многомашинные ассоциации.

Термінальні комплексы.

Перші многомашинные асоціації з’явилися торік у початку 1960;х років і це було з двома проблемами. Перша проблема — проблему забезпечення масового доступу до обчислювальним ресурсів деякою обчислювальної системи. Друге — поява завдань, вимагали можливість притягнення для розв’язання більш як однієї обчислювальної системи. З погляду інтелектуалізації многомашинных асоціацій, першим типом многомашинных комплексів був термінальний комплекс. Термінальний комплекс можна з’ясувати, як набір програмних і апаратних коштів, виділені на взаємодії користувачів з обчислювальної установкою, через телефонну чи телеграфну мережу (чи через будь-яку іншу середу, якою можна забезпечити связь).

Структуру термінального комплексу можна зобразити наступним образом:

Є обчислювальна система, є канал взаємодії з зовнішнім світом, якого включено пристрій, зване мультиплексер. Це пристрій, що забезпечує взаємодія групи зовнішніх пристроїв з обчислювальної системою (ЗС) через один канал ввода/вывода. До каналам мультиплексора може бути підключені локальні терминалы.

З іншого боку то, можливо включено пристрій, зване модемом. Модем дозволяє у телефонну чи телеграфну мережу, працюючу в аналоговому режимі, і передавати інформацію (модему, на другий частини мережі). До модему підключається віддалений термінал. Модем перетворює дискретний сигнал, що надходить від ЗС (чи термінала), в аналоговий сигнал, які вже можна передавати через мережу; і навпаки — аналоговий в дискретный.

Телефонна мережу складається з якогось набору телефонних станцій, і її надає т.зв. комутований канал. Суть його у цьому, що з кількох дзвінках одного й тому абоненту, раз від разу маршрути комутації (тобто. набір дротів, якими йде повідомлення) відрізняються одна від друга, завдяки тому, що завжди вибираються вільні каналы.

Можливо також багаторівневе мультиплексування. Замість віддаленого термінала, підключається віддалений мультиплексер, починаючи від цього може бути продовження цього ж рівня малюнків. Це означає, що ми, працюючи за терміналом другого (чи третього, четвертого, тощо.) рівня істотно завантажуємо коммутируемую линию.

Лінія зв’язку, яка пов’язує один віддалений термінал з комп’ютером, називається лінією зв’язку типу точка-точка. Ця лінія може або орендованій (ми домовляємося з телефонними станціями і фіксуємо комутацію), або коммутируемой.

Канал то, можливо многоточечным. У цьому на вході перебуває віддалений мультиплексер. Багатоточкові канали також можуть бути або арендуемыми, або коммутируемыми.

Типи каналів связи:

1. Симплексные канали — канали, якими передача інформації ведеться щодо одного направлении.

2. Дуплексные канали — канали, що забезпечують одночасну передачу інформацією двох направлениях.

3. Полудуплексные канали — канали, що забезпечують передачу інформацією двох напрямах, але у кожен час лише у один бік (подібно рации).

ЗС має комплекс програм, що забезпечують взаємодія користувачів крізь усе комунікаційну середу, з ЗС. Як локальних віддалених терміналів можуть бути присутні як реальні термінальні устрою, і комп’ютери, які эмулируют роботу терминала.

Многомашинные обчислювальні комплексы.

Многомашинные обчислювальні комплекси (ММВК) — це програмно апаратне об'єднання групи обчислювальних машин которых:

1. В кожній з машин працює своя операційна система (цей ознака відрізняє ММВК від многопроцессорного обчислювального комплекса).

2. У ММВК є загальні фізичні ресурси (отже є проблеми синхронізації доступа).

ММВК використовувались у ролі систем збирання та опрацювання великих наборів даних, й у організації глобальних термінальних комплексів. ММВК з’явилися торік у початку 60-х і він продовжують успішно існувати. Один із основних застосувань ММВК — це дублювання обчислювальної мощі, прикладом таких систем може бути будь-яку систему управління важливими технологічними процессами.

Обчислювальні сети.

І термінальні комплекси, і ММВК вважатимуться приватним випадком обчислювальних мереж, проте хронологія розвитку многомашинных асоціацій була такою — спочатку з’явилися термінальні комплекси, потім ММВК, потім обчислювальні сети.

Припустимо ми маємо деяка група обчислювальних машин, які ми називати абонентськими машинами (ГАМ). Є деяке освіту, що називається комутаційної середовищем. Комутаційна середовище включає канали передачі, щоб забезпечити взаємодія між машинами, спеціальні обчислювальні машини, які ми називати коммутационными машинами. Абонентські машини можуть здійснювати взаємодію одне з одним через коммутационную середу, у межах якої використовуються канали передачі і комутаційні машини. [pic].

Є низка класичних різновидів сетей.

Мережа комутації каналів. Суть її у тому, що й треба зв’язати АМ2 з АМ3, це відбувається з'єднання каналів і комутаційних машин між тими ГАМ. Це з'єднання існуватиме остаточно взаємодії АМ2 і АМ3. Гідність цієї мережі у цьому, що швидкість взаємодії між машинами дорівнює швидкості самого повільного компонента мережі, що у зв’язку (це максимально можлива швидкість). Недолік у цьому, що ця зв’язок може блокувати інші сполуки (у разі АМ1 і АМ4 не зв’яжуться остаточно зв’язок між АМ2 і АМ3). Піти від цього проблеми можна вимагаючи комутаційної середовища великий надмірності, тобто. організувати додаткові (дублюючі) каналы.

Мережа комутації повідомлень. Якщо комутація каналів — це комутація на час всього сеансу зв’язку, то комутація повідомлень — це зв’язок, коли він весь сеанс поділяється передати повідомлень (повідомлення — деяка, логічно завершена, порція даних), і комутація відбувається на період передачі повідомлення. У такій мережі на комунікаційні машини лягають великі навантаження, вони мають також мати можливість буферизации повідомлень у зв’язку з нерівномірної швидкістю передачі різними ділянках мережі. Переваги — простота логічна фізична, недоліки — зниження швидкості роботи у мережі, і, пов’язані з буферизацией.

Мережа комутації пакетів. Сеанс розбивається на повідомлення, повідомлення розбиваються на порції даних однакового обсягу — пакети. По мережі переміщаються не повідомлення, а пакети. Тут спрацьовує принцип гарячої картоплі: основна дія комутаційної машини — якнайшвидше позбутися пакета, визначивши кому його далі можна перекинути. Т.к. все пакети однакового обсягу, немає проблеми з буферизацией, оскільки ми можемо розрахувати необхідну буферну здатність комутаційних машин. Логічно відбувається досить швидке з'єднання, оскільки мережу комутації пакетів практично немає ніякого ситуацій, коли якісь канали заблоковані. за рахунок те, що відбувається роздрібнення сеансу на пакети, є можливість оптимізації обробки помилок під час передачі даних. Якщо ми маємо помилку як комутації каналів, треба повторювати весь сеанс, тоді як режимі комутації повідомлень, треба повторювати повідомлення, відразу ж досить повторити передачу пакета, у якому виявлено ошибка.

У реальних системах використовуються багаторівневі мережі, які у якихто режимах працюють у режимі комутації каналів, у якихось режимах працюють у режимі комутації повідомлень тощо. Сьогодні можна сказати, що мереж, що належать суто до жодного з перелічених вище типів, нет.

Стандарт ISO/OSI.

Розвиток многомашинных асоціацій взагалі, та мереж ЕОМ зокрема, визначило виникнення необхідності стандартизації взаємодії, що у мережі. Тому наприкінці 70-х початку 80-х ISO (International Standard Organization) запропонувала т.зв. стандарт взаємодії відкритих систем ISO/OSI (Open System Interface).

Була запропонована семиуровневая модель організації взаємодії комп’ютерів з середовищем передачі, з тими програмами, функціонуючими на різних комп’ютерах, і взагалі разі організація взаємодії мережі. Пропонувалися до розгляду сім рівнів взаємодії: |VII|Прикладной рівень | |VI |Представницький | | |рівень | |V |Сеансовый рівень | |IV |Транспортний рівень | |III|Сетевой рівень | |II |Канальний рівень | |I |Фізичний рівень |.

Фізичний рівень або рівень поєднання з фізичною каналом. У цьому рівні вирішуються самі земні питання взаємозв'язку: це питання рівнів і типів сигналів, тощо. Цей рівень визначає конкретну фізичну середу. Припустимо, фізичної середовищем то, можливо середовище, яка називається «вита пара », чи середовище, що називається «коаксіальний провід », чи середовищем то, можливо оптоволокно, тощо. Кожна з цих фізичних середовищ визначає свої умови спілкування них. Канальний рівень. У цьому рівні формалізуються правила передачі через канал. Якщо фізичний рівень пов’язаний безпосередньо з середовищем (з каналом), то канальний рівень пов’язані з передачею інформації з цьому каналу. Мережний рівень. Цей рівень управляє зв’язком у мережі між машинами. Тут вирішується питання адресації і маршрутизації даних. Транспортний рівень. Цей рівень іноді називають рівнем логічного каналу. У цьому рівні вирішуються проблеми керування передаванням даних, і пов’язані з тими проблемами завдання — локалізація та обробка помилок, і безпосередньо сервіс передачі. Сеансовый рівень забезпечує взаємодія програм (зрозуміло, що машини власними силами не взаємодіють, а взаємодіють програми). У цьому вирішуються проблеми синхронізації обміну даних, скасування сеансу внаслідок фатального результату, підтвердження паролів. Представницький рівень. У цьому рівні вирішується з поданням даних. Зрозуміло, що різні системи мають різні форми уявлення даних. Прикладний рівень. На прикладному рівні вирішуються проблеми стандартизації взаємодії з прикладними системами.

Отже, було запропоновано така семиуровневая модель, і це запропоновано використати цю модель у двох якостях: стандартизація взаємодії мережі (розробка стандартів) й застосування їх цієї модель для практичних рішень. Стандарти на фізичний рівень вже розроблено, розробляються стандарти на канальний рівень. На жаль, реальні мережі відповідають такий семиуровневой моделі, хоча інколи можна знайти деяке соответствие.

Вважається, що у кожної з ЗС, які у мережі, існує набір рівнів мережного взаємодії, відповідний такий семиуровневой моделі. У цьому вважається, що гарантовано у мережі існують поспіль що йдуть рівні знизу вгору. Тобто. є сеансовый рівень, то гарантовано є всі нижестоящие.

Ми маємо дві машини, з кожної у тому числі реалізовано цю семиуровневая модель. Система взаємодії передбачає таке взаємодія між машинами, коли кожен рівень спілкується з подібним рівнем. Правило взаємодії систем на однойменних рівнях, називається протоколом передачі. У цьому однойменні рівні реально безпосередньо друг з одним оперувати що неспроможні. Вони оперують друг з одним через нижчі рівні й фізичну середу. Будь-який рівень нашої моделі може безпосередньо взаємодіяти тільки з сусіднім рівнем (або сусіднім згори, або знизу). Правила взаємодії між рівнем називаються інтерфейсом. Якщо хтось рівень звертається до іншого (на другий машині) через протокол передачі, насправді відбувається звернення через відповідну послідовність інтерфейсів до нижчестоящим рівням, далі відбувається передача через фізичну середу, і далі відбувається послідовна передача від нижчестоящого рівня до нужному.

Сутність стандартизації у тому, що після ухвалення стандарту цих рівнів, можна вже змінювати реалізації рівнів або додавати нові рівні, не турбуючись про інтерфейсах і протоколах. Стандартизація визначає совместимость.

Трохи про Интернет.

Ми із Вами поговоримо трохи про Інтернет, але з огляду на те, що мені кажуть на екрані телевізора, причому часто кажуть речі відверто дурні, а сточки зору її устройства.

Кілька слів про передісторії. Наприкінці 1960;х років американське агентство перспективних досліджень, у обороні DARPA прийняв рішення створенні експериментальної мережі під назвою ARPANet. Основним властивістю цієї мережі було те, що передбачалося відсутність будь-якої централізації. Цей проект почав розвиватися. У 70-ом року ARPANet стала вважатися діючої мережею навіть зокрема, цю мережу можна було добиратися до провідних університетських і наукових центрів США. На початку 80-х почалася стандартизація мов програмування, та був протоколів взаємодії мереж. Тут є дві моменту, вплинули на поява Інтернет. Перший — це є факт стандартизації. Друге — поява моделі ISO/OSI. Этогт момент вважатимуться початком появи Интернета.

Лекція № 23.

Ми почали обговорювати проблеми організації Інтернет, і позначили основну рису цією системою, закладене спочатку — що ця мережа абсолютна симетрична з тим погляду, що вона передбачала якийабо централізації і ієрархії. Це властивість, яке лягло основою мережі, і створило той бум, що спостерігається зараз, тобто Інтернет може вільно расширяться.

Ми із Вами розглянули коротенько передісторію мережі. Спочатку мережу передбачала суто експериментальну роботи й вже у подальшому отримала університетську поширеність, комерція ж прийшла б у Інтернет разів у 1994;95 годах.

Інтернет грунтується на протоколах TCP/IP (Transfer Control Protocol / Internet Protocol). Інколи мені кажуть: «протокол TCP/IP» — але ці неправильно, бо під цієї абревіатурою ховається ціла набір протоколів, об'єднаних одна назва. До речі, тут є окремо протокол TCP і окремо протокол IP.

Сімейство TCP/IP будується по чотирирівневої схемою. Розглянемо таблицю відповідності TCP/IP моделі ISO/OSI:

|Уровни TCP/IP |Рівні ISO/OSI | |I. Прикладних програм |Прикладних програм | | |Уявлення даних | |II. Транспортний |Сеансовый | | |Транспортний | |III. Міжмережевий |Мережний | |IV. Доступу до неї |Канальний | | |Фізичний |.

Рівень доступу до неї TCP/IP забезпечують апаратні інтерфейси і драйвери цих апаратних інтерфейсів. Приміром, протоколами рівня доступу до неї є протоколи Ethernet. Їх серцевина в следующем.

Ethernet — це система, забезпечує «миттєвий «доступ з «контролем несучою «і виявленням сутичок. Ethernet — широковещательная мережу, це, що будь-який повідомлення, що виходить з джерела стає видимим решті Ethernetпристроям. Ethernet симетрична (немає ніякої фізичного верховенства), вона не передбачає наявність деякою фізичної середовища (різновиду коаксіального кабелю, кабель «вита пара», НВЧ діапазон та інших.), Ethernet-устройства, яке здійснює взаємодія у межах даної середовища. Оскільки мережу симетрична, виникає проблема зіткнення пакетів що передаються даних, тобто, коли одночасно посилаються два пакета даних із різних пристроїв — у разі відбувається відмова передачі в обох пристроїв, після цього завмирають на кілька днів, та був роблять ще не одну спробу. Нагадує розмова чемних людей темній кімнаті: якщо одна людина каже, інші мовчать; коли, двоє, починають говорити, то обидва одночасно замовкають і роблять паузу.

Наступне властивість Ethernet у тому, що з Ethernetпристроїв має унікальний адресу, ця адреса присвоюється йому за виготовленні. Є низка усталеними міжнародними правилами, які створюють неможливим появу у світі двох Ethernet-устройств з номером, чи то вже згорілі устрою або ще перебувають у строю. Цей адресу можна порівняти зі штрих-кодом, який зустрічається в різних продуктах.

Ще один властивість Інтернет — широковещательность. Реально, будь-яке повідомлення, надіслане до мережі, проходить крізь ці Ethernet-устройства мережі. Відповідно, всі повідомлення мають адресацію, та шляхів сполучення можуть адресуватися всім пристроям, або певній окремій, але у будь-якому разі - повідомлення пройде крізь ці устрою, тож якусь-там всі вони саме вирішить — залишити його нет.

От у кількома словами на зразок четвертого рівня доступу протоколів TCP/IP, це найпоширеніший варіант. Можна сміливо сказати про тому, що ця мережу проста, однак має ряд недоліків, яке у тому, що коли мережі виникає багато активних користувачів, то частішають зіткнення повідомлень і пропускну здатність істотно снижается.

Слід звернути увагу, коли ми говоримо Інтернет — мережу, то це теж вірно, як і те, що TCP/IP — протокол. Тобто Інтернет — це об'єднання сетей.

З цього погляду можна назвати два виду комп’ютерів, які можна назвати у мережі: [pic].

Це хост-компьютеры (host) і шлюзи (gate). Двома словами покажемо, що є що. Реально, кожен із комп’ютерів, який працює у мережі, може класифікуватися з двох ознаками. Якщо комп’ютері розташована лише одна мережна карта чи інтерфейс, це хост-компьютер і звичайно він належить якоюсь однією мережі. Якщо комп’ютері перебувають дві і більш мережевих карт, у своїй кожна гілка карт підключається зі своєю мережі, то такий комп’ютер називається компьютером-шлюзом. Відповідно, через шлюзи можна об'єднувати сети.

Тобто, коли дивитися з погляду приналежність до мереж — хост належить однієї мережі, а шлюз належить відразу двом чи більше мереж. Через шлюзи здійснюється взаємодія між комп’ютерами у різних мережах. І це механізм об'єднання і доступу є одним із відмінностей Інтернету, що базується на межсетевом рівні TCP/IP, який у часи чергу виходить з протоколі IP.

Основна функція протоколу IP — унікальна міжмережний адресація. Однією з основних властивостей чи якостей IP-протоколу є IP-адрес. Це адресу, який приписується як конкретної мережі, і конкретному комп’ютера у мережі. Виходячи з цього, ми можемо сказати, що шлюз — це комп’ютер, має чи більш IP-адреси (адресу лише у сіті й на другий мережі), хост — комп’ютер, має один IP-адрес. Також, у функції IP входить маршрутизація, тобто вибір шляху, яким передаватимуться повідомлення, визначення базових блоків даних (вони називаються дейтаграммы), що передаються, і їхню взаємодію з транспортним рівнем та вищим рівнем доступу до неї. Відповідно, у зв’язку з цим взаємодією можлива фрагментація і дефрагментация дейтаграмм.

Кілька слів про IP-адресации. IP-адрес — це четырехбайтовый код, в якому може розміщатися інформація про адресі сіті й про адресі комп’ютера у мережі. Є кілька категорій IP-адресов:

Клас А. |0 | | | | | |1 байт |2 байт |3 байт |4 байт |.

Перший байт кодує номер мережі, у своїй його старший біт є нульовим (це — ознака класу А), інші біти визначають номер мережі. Сетей класу Можливо 126 штук. Відповідно, останні байта — номер комп’ютера у мережі. Мережі класу, А — гігантські мережі, що потенційно можуть належати найбільшим корпорациям.

Клас B. |1 |0 | | | | | |1 байт |2 байт |3 байт |4 байт |.

Ознака класу B — старші два біта рівні «10». Для нумерації мережі використовується залишок першого вчителя і повністю другий байт. 3 і 4 байти — номер комп’ютера у мережі. І це великі мережі, їх то, можливо велике кількість, але й ограниченное.

Клас З. |1 |1|0| | | | | |1 байт |2 байт |3 байт |4 байт |.

Ознака класу З — старші три біта рівні «110». Для нумерації мережі використовуються: залишок першого байта, другий і третій байти повністю. Номер комп’ютера визначається четвертим байтом. Відповідно, клас З представляє безліч невеликих сетей.

Є решта 2 класу — D та О, але де вони досить специфічні, і ми будемо про неї говорить.

Існує міжнародна організація, яка розподіляє номери мереж. Тут спрацьовує певна ієрархія. Організація, отримавши номер мережі може розподіляти номери комп’ютерів не більше цієї мережі по власному усмотрению.

Слід зазначити, що, попри величезний число адрес, яке можна чотирма байтами, існує проблема їх узкости, і йдуть розмови про розширення IP адресації. Це колосальна проблема, порівнянна хіба що проблемою 2000 года.

На межсетевом рівні крім протоколу IP є ще група допоміжних протоколів. Частина залежить від цього, чому ми будемо користуватися й що ми робитимемо. У кожному разі - основа їм — протокол IP.

Наступні протоколи — транспортні. Тут присутній два типу протоколів — UDP (User Datagram Protocol) і TCP.

Протокол TCP забезпечує передачу даних із контролем і виправленням помилок. З іншого боку, TCP гарантує логічне з'єднання. Тобто TCP дозволяє створювати логічні канали, гарантуючи відправку і достойний прийом порцій даних у порядку. Протокол жорсткий, оскільки контролює помилки. Але на треба платити, і TCP є ресурсоємним протоколом.

Протокол UDP — це швидка доставка повідомлень без здійснення контролю доставки. Протокол TCP більше вміщує використання у Інтернеті (передачі на великі відстані, де немає може гарантуватися безпомилковість передачі). UDP орієнтовано роботу у локальної мережі, де гарантовано певний рівень якості передачі. Протоколи транспортного рівня спілкуються з прикладними протоколами і міжмережними протоколами.

Далі йде рівень прикладних систем. TCP/IP має тим властивістю, що у сімействі цих протоколів стандартизовані протоколи, у яких базуються прикладні системи. Зокрема, FTP (File Transfer Protocol). Реально система FTP є у кожної операційній системи та у кожному набір FTP систем то, можливо значним. Але завдяки тому, що є стандарт FTP, всі ці докладання працюють однаково. Є мережевий продукт Telnet — мережна эмуляция алфавитно-цифрового терминала.

Тобто системі стандартизовані протоколів із допомогою яких організовані прикладні системи. І ми можемо будувати свої докладання FTP чи Telnet з наданих кирпичиков.

Різні прикладні системи спілкуються з різними протоколами — хтось із UDP, хтось із TCP. FTP і Telnet, наприклад, працюють через TCP, а мережна файлова система NFS, що дозволяє об'єднувати файлові системи різних машин одну (і бачити їх постійно, як свій локальну), полягає в UDP, тому що NFS працює у рамках локальної сети.

От і всі, можна було сказати про многомашинных асоціаціях, протоколах і за курсом в целом.

———————————;

Обчислювальна система.

Мультиплексор

М.

…

М.

М у л т т і п л е до з про р

М.

Телефонна станция Модем Терминал.

М.