Компютърни мрежи

5.4.Мрежови протоколи

5.4.1.Протокол X.25.

Фиг.5.7. = фиг.8.4 (а)

X.25 като мрежов протокол се интегрира в протоколен “стек” изграден на физическо ниво от интерфейса X.21, Х.21 осигурява взаимодействието и преноса на битов поток между локалните DTE – DCE (връзката компютър-модем). Каналното ново на Х.25 протоколния стек е реализирано на базата на версия на протокола HDLC – LAP B. LAP B предоставя на мрежовото ниво услуги по отношение на достоверния информационен пренос на информацията до “входа” на пакетната мрежа – пакетния комутатор (PSE – Packet Switch Equipment). X.25 протоколния стек се изгражда до транспортно ниво на базата на протокол TPDUs (Transport Protocol Data Units) –този протокол осигурява възможност за мултиплексиране на точките на достъп до услугите на мрежовото ниво -X.25 и реализиране на повече от една виртуални вериги на базата на една точка на достъп до мрежовите услуги - NSAP (Network Services Access Point).

Физическо ниво на протоколния стек X.25 – X.21

Физическият интерфейс за връзка между комуникиращите си компютри (DTE) и поддържаните от локалната мрежа за масово обслужване модеми (DEC) се специфицира от препоръка X.21. DCE има за задача да синхронно дуплексно съединение между крайните компютри и прилежащите им входни точки в пакетната мрежа – пакетните комутатори (PSE) Като подмножество на стандарта EIA –232D/V.24 X.21 осигурява скорости на обмен от 600 bps (бит за секунда) до 64kbps (килобит за секунда). На фиг.5.8. е представена конфигурацията на сигналните вериги на X.21 като част от протоколния стек X.25

Фиг.5.8. = фиг.8.6

Канално ниво на протоколния стек X.25 – HDLC – LAP B

Структурата на кадрите, управлението на потока кадри и отстраняването на грешките при предаване в протоколния стек на X.25 се реализира съгласно процедурите на протокол HDLC. HDLC се прилага в балансен режим (ABM) , специфицирани в документите за производния протокол LAP B.

Използвайки ABM крайния компютър (DTE) и локалния пакетен комутатор (PSE) работят независимо (асинхронно), т.е всеки един от тях може по всяко време да бъде инициатор на команди и да генерира потвърждение на вече изпратени команди. Тъй като съединението между крайния компютър и локалния комутатор е двуточково, то не се налага адресна трансформация на глобалните мрежови адреси. На канално ниво е достатъчно адресното поле да съдържа адреса на модема (DCE), свързан към локалния комутатор, за да достигнат кадрите от мрежовия слой на DTE до мрежовия слой на локалния PSE – фиг.5.9.

Фиг.5.9. = фиг. 8.7(b)

На мрежово ниво X.25 поддържа съединения между точки на достъп до мрежовите услуги (NSAP), като се осигурява възможност за реализиране на повече от една предварително установени и установяващи се виртуални за всяка валидна NSAP от пакетната среда.

Фиг.5.10 = фиг.8.9(b)

Адресното поле от йерархична гледна точка е разделено на две части: Initial Domain Path(IDP) и Domain Specific Path (DSP), т.е идентификатор на мрежовата област (домейн) – IDM и локален зонов (вътрешен за домейна) идентификатор – DSP. Максималната дължина на X.25 адреса е 40 десетични цифри, представени в BCD-код на 20 байта.

Частта за идентификация на мрежовата област (IDP) се състои от две полета:Authority and Format Identifier (AFI) и Initial Domain Identifier (IDI) . Полето AFI е “административно” поле то показва съгласно коя версия на адресната схема е структуриран X.25 адреса. Адресният синтаксис е функция на няколко стандартизирани формата. Полето IDI e полето за действителната идентификация на мрежовата област и то е част от реалния адресен синтаксис.

За пакетните среди за масово обслужване е приета спецификацията X.121, която определя за формата на адреса: 14 десетични цифри за IDI-полето и 20 десетични цифри за DSP-частта.

DSP-частта, съдържа приложния идентификатор на крайния компютър и е съставена от три полета:

• 
  Идентификатор на подмрежата – SI (Subnet Identifier). Определя подмрежата, към която принадлежи конкретния адрес;
  
• 
  Идентификатор на точката на включване – PA(Point of Attachment). Това поле определя физическия адрес на включването на крайния компютър, този адрес още се нарича X.25-порт адрес;
  
• 
  Локален идентификатор – SEL (SELector) – Това поле се използва за вторично локално адресиране и не се използва за целите на маршрутизирането. Използва се за мултиплексиране на физическия адрес на включване и адресирането на повече от едно устройства (компютри и терминали) през един PA.
  

X.25 пакетите имат структура съставена от фиксирана заглавна част (header) и тяло на пакета, което съдържа служебни команди или данни – фиг.5.11.

VCI – идентификатор на виртуална верига





4

8

8



Групов форматен идентификатор

GFI

Group Format Identifier

Номер на логическа група

LGN

Logical Group Number

Номер на логически канал

LCN

Logical Channel Number

Поле за тип на

пакета

TYPE


1
0




Q


D

Размер на прозореца

10 – 8 пакета

01-128 пакета

Ф
1 – служебен пакет

На базата на представеният на фиг.5.11 формат на X.25 –пакета се развива функционалността на мрежовия протокол:

• 
  Установяване на виртуална верига – X.25 е типичен представител на ориентираните към връзката (Connection Oriented Network Services - CONS) мрежови протоколи. Между два валидни X.25 адреса (NSAP -адреси) се установява съединение с определени параметри (качество на мрежовото обслужване), по което преминават двупосочно множеството пакети, свързани с текуща приложна сесия – този тип съединение се нарича “виртуална верига” (VC – Virtual Circuit). При установяването на X.25 VC се използва команден примитив, който има следните параметри:
  

-обема на потребителските данни, които ще се обменят по тази верига;

-качество на мрежовото обслужване;

По NSAP-адреса параметризираната заявка достига до локалния комутатор (PSE), към който е свързан целевия компютър (DTE), PSE избира поредния свободен номер на VC – идентификатор на виртуалната верига (VCI – виж фиг.5.11) и връща потвърждение към PSE на компютъра-инициатор, като в потвърждението се указва стойността установената вече VCI – VCI₁. След предаването на заявения обем информация. Компютърът-инициатор “освобождава” локалния PSE от отговорността да поддържа виртуална верига VCI₁. След това компютърът-инициатор изпраща команден примитив до целевия компютър за разпадане на виртуална верига VCI₁ идентификатор. Целевия компютър “информира” локалния PSE за разпадането на верига VCI₁ – идентификатора се освобождава, с което ресурсите, поддържащи веригата окончателно са освободени.

• 
  Обмен на информация – след установяване на VC по нея компютрите (DTE) започват обмен на приложна информация. Обменят се пакети с данни с максимален размер до 128 октета. Ако приложното съобщение е по-голяма дължина, то се фрагментира на части. При изпращането на поредната част от съобщението в заглавието на пакета се установява в “1” служебен бит –M (more-data). Установяването на този бит показва, че това е междинен за съобщението пакет и предстои предаването на останалата част от съобщението. Ако бит Q от заглавието е установен в “1” – виж.фиг.5.11, то в пакета е записано съобщение, структурирано от транспортния протокол на X.25 стека – TPDU. Тогава в целевия компютър, TPDU-обекта извлича данните от пакета и ги интерпретира, съгласно процедурната си логика. Ако бит D от заглавието е установен в “1”, то DTE-източника изисква отдалечено потвърждение от целевия DTE, при “0” потвърждението се получава само от локалния PSE.
  
• 
  Управление на потока пакети – управлението на потока пакети между DTE и локалния PSE се реализира на канално ниво. По съединението PSE-PSE се провява характерната за мрежовия протокол техника за управление на пакетите- ARQ с пълзящ прозорец. Размера на прозореца се определя от стойността на два бита от заглавието на пакета и може да приема две стойности 8 и 128. В единия случай се потвърждават едновременно 7 пакета, а в другия случай 127 пакета.
  
• 
  Отстраняване на грешки – за мрежовия протокол на X.25 стека е характерна техника за отстраняване на грешки с изборно повторно предаване (Selective Repeat). Характерна особеност на протокола е, че не се допуска “отварянето” на нов прозорец с кадри, докато има недостоверно приети кадри от предходния прозорец. Ако се получат пакети с номера различни от размера на прозореца, то се инициализира ситуация на липса на синхронизация. Виртуалната верига временно се разпада и се възстановява отново, с цел да се синхронизират DTE –та, участващи в обмена.
  

За използването на X.25 в архитектури на взаимодействие с участието на непакетни устройства (DTE) са създадени няколко съпътстващи спецификации, определящи начина на реализация на мрежовото съединение при възможните сценарии на свързване – фиг.5.12

Фиг.5.12 = 8.17

Дефинира се функционално завършен протоколен обект –PAD (Packet Assembler - Dissassembler). Функционалността на PAD се свързва с осигуряването на възможност за достъп до пакетната среда от асинхронни символни терминални устройства. Терминалът изпраща към PAD-а асинхронна последователност от символи, която се пакетира и се изпраща към локалния PSE. Функционалността на PAD е дефинирана в препоръка X.3. PAD поддържа както протоколната спецификация на X.25, така и характерната параметризация и специфични особености на символните терминали като крайни устройства .

Установяването на съединението между отдалечен асинхронният символен терминал и PAD се основава на базата на основен подразбиращ се профил (множество) от параметри. Всички изменения от подразбиращият се профил се реализират, чрез процедура за формализация на стандартен профил за конкретния терминал. Тази процедура е дефинирана в препоръка X.28 (фиг.5.12б)

Препоръката X.29 специфицира взаимодействието между PAD и отдалечен пакетен краен компютър (DTE). Основната допълнителна функционалност, която внася X.29 в протоколния стек на X.25 е процедурата за идентификация на типа на символния терминал в момента на установяване на съединението. Първите 4 октета от полето за потребителски данни имат за цел на идентифицират протокола за обмен между терминала и пакетния DTE. На базата на полето за протоколна идентификация пакетния DTE преконфигурира протоколите от “високите” архитектурни нива, така че да се реализира достоверно приложно съединение със символния терминал с участието на PAD. Бит Q се установява в “1”, с което се указва, че в полето за данни има пакетирана протоколна спецификация от по-“високо” ниво.

Основните проблеми при взаимодействието на X.25 мрежи се свързват с необходимостта от адресно преобразуване, форматно преобразуване и “зашиване” (пренасочване, комутиране) на виртуалните вериги с цел установяването на съединение между DTE от различни X.25 мрежи – фиг. 5.13

Фиг.5.13 = фиг.8.20

Процедурите по протоколното съгласуване между X.25 мрежови конфигурации са дефинирани в препоръка X.75. С X.75 се в “света” на X.25 функционалните обекти един нов обект, наречен сигнален терминален преобразувател – STE (Signaling Terminal Exchange). Основната функция на STE е пренасочването и поддържането на VC, независимо от броя на X.25 мрежите, през които преминава виртуалната верига по пътя си. Функционалността на X.75 се реализира с въвеждането на допълнително служебно поле в пакета – поле за характеризиране на параметрите на мрежата – NUF (Network Utility Field). На базата на информацията от това поле се съгласуват и синхронизира поддържането на виртуалните вериги от гледна точка на адресирането, формата на пакетите, техниките за контрол на потока пакети и отстраняване на грешките при предаване.

5.4.2.Мрежов протокол IP (Internet Protocol).

Структурата на протоколния стек IP и мястото му в еталонната архитектура е представена на фиг.5.14

фиг.5.14

Мрежовото ниво на протоколния стек TPC/IP включва протоколите, предствени на фиг.5.14:

IP (Internet Protocol) e дейтаграмен мрежов протокол, осигуряващ несвързано мрежово обслужване. IP е протокол, който осигурява маршрутизирането на дейтаграмите от адреса-източник до целевия адрес, без да носи отговорност за достоверността на преноса на информацията и отстраняването на възникнали при предаването грешки. Протокола поддържа йерархична адресна логика и осигурява глобален обмен на еднопосочни съобщения (дейтаграми).

ICMP (Internet Control Message Protocol) e протокол за обмен на служебни съобщения на мрежово ниво. Използва се за управление и диагностика на състоянието на мрежовите съединения и обработване на аварийни ситуации.

ARP (Address Resolution Protocol) e протокол за намиране на адресно съответствие по валиден IP адрес. Той съпоставя IP (мрежовия адрес) на системата с нейния канален (физически) адрес (МАС-адрес).

RARP (Reverse Address Resolution Protocol) e протокол за намиране на адресно съответствие по валиден MAC адрес. Този протокол извежда съответствието между известен канален (физически) адрес (МАС-адрес) и присвоения на системата IP-адрес (мрежов адрес)

5.4.3.Структура на IP адреси.

Адресната логика на протокол IP е йерархична. Адресното поле на протоколната спецификация е 32-битово като са дефинирани 3 базови формата (класове) адреси A,B, и C. Всеки клас се интерпретира и използва за адресиране в условията на различни по структура и размерност мрежови конфигурации - фиг.5.15

Фиг.5.15 = фиг.9.8

Първите 4 бита от адреса определя класа на мрежа. Останалите 24 бита се разделят на две части: мрежов идентификатор (network identifier - netid) и идентификатор на краен компютър (host identifier - hostid).

Адресите от клас А са със 7-битово поле на netid и 24-битово поле за hostid.

Адресите от клас B са с 14-битово поле на netid и 16-битово поле за hostid.

Адресите от клас C са с 21-битово поле на netid и 8-битово поле за hostid.

Клас А-адресите се използват при мрежови конфигурации с голям брой крайни компютри (до 2²⁴), докато клас C-адресите позволяват идентификация на голям брой подмрежи с относително малко крайни компютри във всяка от подмрежите (до 256). Един типичен пример за клас А мрежа ARPANET, a пример за клас C мрежа е една малка корпоративна мрежа в завод, училище, общинска администрация и т.н.

Когато полето hosted е нула , то адреса се нарича адрес на мрежа (подмрежа). Когато полето hosted е запълнено с 1, то адреса , който се формира адресира едновременно всички крайни компютри в текущата. Такъв адрес се нарича общ или групов адрес (broadcast address).

За целите на по-ефективното и разбираемо представяне на IP адресите, 32-битовия адрес е разделен на 4 октета, като стойността на всеки октет се представя с дедетичния си еквивалент. Октетите се разделят с точка, например

00001010 00000000 00000000 00000000 = 10.0.0.0 = Клас А : netid = 10

(ARPANET)

10000000 00000010 00000011 00000011 = 128.2.3.3 = Клас B : netid=128.2

hosted=3.3

11000001 00000000 00000101 11111111 = 193.0.5.256 = Клас C : netid= 193.0.5

hosted=до всички

крайни компютри

в подмрежа 193.0.5

(broadcast address)

5.4.4.Формат на IP дейтаграмите

Мрежовият протокол IP поддържа формат на пакетите (дейтаграмите), предствен на фиг.5.16

Ф
Битова последователност (0-15)
ормат на IP пакета

0

3

4

7

8

11

12

15

Version

Header Length

Type of Service

Total Length

Identification

D

M

R

Fragment Offset

Time to Live

Protocol

Header Checksum

Source IP address

Source IP address

Destination IP address

Destination IP address

Options

Options

Data

Фиг. 5.16

Описание на полетата на IP пакета (datagram):

1) Version – версия;

2) Header Length – дължина на заглавната част;

3) Type of Service – тип на услугата;

4) Total Length – обща дължина;

5) Identification – идентификация;

6) Fragment Offset – отместване на фрагмента;

7) Time to Live – време на живот;

8) Protocol – протокол;

9) Header Checksum – контролна сума на заглавната част;

10) Source IP address – IP адрес на източника;

11) Destination IP address – IP адрес на получателя;

12) Options – допълнение;

13) Data – потребителски данни.

1. 
   Version – версия съдържаща текуща версия на IP протокола. Текущата версия е 4-та - IP v.4
   
2. 
   Header Length – дължина на заглавната част – съдържа действителния размер на заглавието на пакета, представен като брой 32-битови думи. Минималната дължина на пакета, ако не се използват допълнителните полета е 5 32-битови думи.
   
3. 
   Type of Service – тип на услугата – поле, в което компютъра-източникът заявява тип на мрежовата услугата за текущата приложна сесия: висока надеждност; минимално времезакъснение; висока пропускателна способност; прилагане на схема с приоритети.
   
4. 
   Total Length – пълна дължина на пакета (заглавната част и потребителските данни). Максимално допустимия размер на пакета е 65 535 бита
   
5. 
   Identification – идентификация – обикновено едно съобщение се предава под формата на поредица от няколко пакета. Това поле служи идентификация за принадлежност на пакетите към едно и също приложно съобщение.
   

Битове D,M и R – свързани са с т.н. фрагментация на данните.

D – Don’t Fragment – не фрагментирай този пакет. Ако този флаг е усановен в “1” при достигане на мрежа с по-малък размер на пакета, текущия пакет няма да бъде фрагментиран, а ще бъде отхвърлен от тази мрежа. Налага се маршрутизиране по друг път.

M – More Fragments – когато бит М е установен в “1”, то текущия пакет е част (един фрагмент) от по-голям пакет и след него следват още фрагменти.

R – Reserved – резервиран флаг.

6. 
   Fragment Offset – отместване на сегмента. Записва се информация за позицията на полето за данни от текущия фрагмент в оригиналния пакет. Отместването от началото на съобщението се представя като число кратно на 8 октета.
   

Пример

Нека приложно съобщение от 1000 октета да се транспортира през подмрежа, с максимален размер на пакета – 256 октета. Приемаме, че размера на заглавието е 20 октета (5 32-битови думи) и за потребителската информация остават – 236 октета.

Тъй като отместването е каратно на 8 октета, то 29 Х 8 = 232. 29 е най-близкото цяло число, с което може да се представи отместването(Fragment Offset). Ако изберем 30, то 30 Х 8 = 240 октета, при максимум 236. Тогава съобщението от 1000 октета, ще се предаде като полседователност от 5 пакета: 4 Х 232 октета и 1 Х 72 октета, а отместването ще е картно на 29. Стойностите на полетата, свързани с фрагментирането е представена в таблицата


No на пакет	1	2	3	4	5
Identification	20	20	20	20	20
Total Length	252	252	252	252	92
Fragment Offset	0	29	58	87	116
M-flag	1	1	1	1	0

7. 
   Time to Live – време на живот. Стойността се установява във възела-източник и се намалява при преминаването през всеки следващ мрежов възел. След достигане на стойност 0, пакетът се унищожава.
   
8. 
   Protocol – записва се типа на протокола от по-“високо” ниво, който се съдържа тялото на пакета. Използва се за протоколна идентификация в целевия възел.
   
9. 
   Header Check sum – контролна сума
   
10. 
    Source IP address – IP адрес на източника (32 битово число).
    
11. 
    Destination IP address - IP адрес на получателя (32 битово число).
    

1 - 11са задължителни полета.

12. 
    Options – допълнителни възможности. Формата им зависи от приложението:
    

• 
  за сигурност (Security) – полето за DATA от пакета е възможно да се криптографира. В Options се специфицира типа на кодирането.
  
• 
  Source Routing – маршрутизиране от източника. В Options се описва маршрута и по този начин се изключва , маршрутизиращата логика във възлите.
  
• 
  Route Recording – запис на маршрута. В Options се записва информация за маршрута (трасиране на маршрута).
  
• 
  Time Stamp – маркер за време – при желание да проверим времато за транспорт на пакета

  Първият байт на полето Options определя текущо използваната допълнителна възможност.

  
  

5.4.5.Протоколно взаимодействие

На фиг.5.17[] е представено взаимодействието на базовия мрежов протокол IP и свързаните с него транспортни протоколи, осигуряващи свързано мрежово обслужване за приложните заявки.


фиг.5.17

Осигуряването на ориентирано към връзката мрежово обслужване се реализира в този протоколен стек на транспортно ниво, тъй като базовия мрежов протокол е дейтаграмен, т.е. не ориентиран към връзката. Във взаимодействието участват два основни транспортни протоколи:

ТСР (Transmission Control Protocol) e ориентиран към връзката транспортен поротокол с две основни функции:

• 
  Да осъществява управление на предаването на информационни потоци, като открива грешки, получени или неполучени пакети и осигурява тяхното повторно предаване.
  
• 
  Мултиплексиране на точките на достъп до мрежово обслужване при поддържането на приложните заявки.
  

Протоколът IP осигурява еднопосочното предаване на дейтаграми от адреса-източник до целевия адрес. Транспортният протокол TCP осигурява управлението на потока кадри и отстраняване на грешки.

На транспортното ниво в разглеждания протоколен стек освен TCP оперира и протокол за обмен на потребителски пакети UDP (User Datagram Protocol). Този транспортен протокол е дейтаграмен, т.е. не предоставя механизъм за установяване на връзка и се използва за услуги, свързани с управление на мрежовите устройства и обмен на служебни съобщения.

5.4.6.Протокол IMCP

На мрежово ниво в разглежданият протоколен стек функционира протокола ICMP (Internet Control Message Protocol) – фиг.5.18.

фиг.5.18

. Протоколните съобщения на ICMP се пренасят в DATA-полето на IP-дейтаграмите и се използват за обмен на информация за грешки и управляваща информация.

Протоколът използва множество от командни примитиви, които дават информация за състоянието на мрежовото съединение:

• 
  Destination Unreachable (недостижим IP адрес);
  
• 
  Time  to Live Exceeded (изтекло време на “живот”)
  
• 
  Parameter Problem (проблеми при съставянето на дейтаграмите)
  
• 
  Redirect (пренасочване на дейтаграми)
  
• 
  Echo (заявка тест на IP адрес)
  
• 
  Echo Reply (потвърждение за тест на IP адрес)
  
• 
  Timestamp (заявка за времеви маркер)
  
• 
  Timestamp Reply (потвърждение на времеви маркет)
  
• 
  Information Request (заявка за информация за състояние)
  
• 
  Information Reply (потвърждение за информация за състояние)
  
• 
  Address Request (заявка за адресна информация)
  
• 
  Address Reply (потвърждение за адресна информация)
  

Тази служебна информация се използва от приложенията за целите на анализ на състоянието на мрежовото съединение и обработване на ситуации на отказ.

5.4.7.Протоколи ARP и RARP

Един от основните проблеми при реализирането на мрежови съединения между компютри, включени в локални мрежови конфигурации е проблема за взаимодействието между мрежови и канални адреси. Глобалният пренос се осъществява по мрежов адрес, докато мрежовия пакет, се транспортира в локалната мрежа в съответствие с конкретния канален протокол.

ARP се използва за построяване на необходимата за мрежовото съединение таблиcа на съответствието между присвоените на компютрите от локалната мрежа IP-адреси и MAC-адресите. Тази таблица позволява установяването на мрежови съединения, основани на преносната среда в локалната мрежа, например IEEE 802.3 Ethernet. При известен целеви IP адрес, за установяване на съединението е необходимо да се извлече от ARP-таблицата, съответстващия му MAC-адрес. Ако в ARP таблицата няма информация за това съответвествие, то се изпраща IP-дейтагрма с целеви адрес, търсения целеви адрес, която се пакетира в broadcast MAC-кадър. Този кадър достига до всички MAC-адреси в локалната мрежа, т,е достига и до компютъра, чиито IP адрес е целевия IP адрес. Компютърът, потвърждава дейтаграмата, като на канално ниво се формира кадър с канален целеви адрес, адреса на инициатора на мрежовото съединение и канален адрес-източник – търсения MAC-адрес. Пристигайки потвърждението при иницииращия компютър, неговата ARP-таблица се актуализира с липсващия MAC-адрес и са осигурени условията за установяване на мрежово съединение в MAC-преносната среда – фиг.5.19[].

фиг.5.19
Протоколът RARP (Reverse Address Resolution Protocol) е “обратен” по функционалност на ARP. При този протокол се решава обратната задача, по известен MAC-адрес де се получи информация за съответстващия му IP-адрес. Използва се аналогичен подход, като се изпраща broadcast IP-дейтаграма, която достига мрежовото нива и в потвърждението се съдържа търсения IP адрес - фиг.5.20[]

фиг. 5.20

Протоколният стек IP v.4 е в основата на изграждането на глобалната мрежова среда INTERNET , както за проектирането на IP-базирани ведомствени мрежови конфигурации- INTRANET мрежови среди.

Каталог: docs -> Bachelor -> IV%20Kurs -> Sem%20VII
Sem%20VII -> Модул tcp/ip компютърни комуникации
Sem%20VII -> Дисциплина: Компютърни мрежи Упражнение 1
Sem%20VII -> Дисциплина: Компютърни мрежи Упражнение 11 Дисциплина: Компютърни комуникации Упражнение 11
Sem%20VII -> Програма по дисциплината : "интернет технологии" включена в учебния план на специалността: " Компютърни системи и технологии"
Sem%20VII -> Модул Frame Relay Компютърни комуникации
Sem%20VII -> Дисциплина: Компютърни мрежи Упражнение 6
Sem%20VII -> Дисциплина: Компютърни мрежи Упражнение 9
Sem%20VII -> Програма по дисциплината : "мрежово програмиране" включена в учебния план на специалността: " Компютърни системи и технологии"

Изтегляне 1.86 Mb.

Сподели с приятели: