CC BY
24
Синхронний мехатзм зв'язку традицшно1 eipmyaMbHoi машини на асинхронному сиг-HaMi призводить до зростання часу затрим-ки та зниження продуктивност1. В робот1 застосовано мехатзм зв'язку, так званий ком-сокет, що використовуе мгжпроцесор-не переривання (МПП) для синхрошзацй i усунення деяких некорисних nеревiрок паке-тiв. Залучено стльне використання пам'я-тi для скорочення часу копювання даних. Порiвняно з UNIX IPC, ком-сокет володie меншим часом затримки та бЫьшою про-дуктивтстю
Ключовi слова: ефективтсть комутка-ци, ком-сокети, синхротзащя, nеревiркa
пaкетiв, копювання пaм'ятi, час затримки □-□
Синхронный механизм связи традиционной виртуальной машины на асинхронном сигнале приводит к росту времени задержки и снижению производительности. В работе применен механизм святи, так называемый ком-сокет, использующий межпроцессорные прерывания (МПП) для синхронизации и устранения некоторых неполезных проверок пакетов. Задействовано совместное использование памяти для сокращения времени копирования данных. По сравнению с UNIX IPC, ком-сокет обладает меньшим временем задержки и большей производительностью
Ключевые слова: эффективность коммуникации, ком-сокеты, синхронизация, проверка пакетов, копирование памяти, время задержки
УДК 004.002
|DOI: 10.15587/1729-4061.2016.60629|
побудова та використання м1ждоменного механ1зму зв'язку для
високопродуктивноТ
обробки даних
В. М. Мельник
Кандидат фiзико-математичних наук, доцент* E-mail: melnyk_v_m@yahoo.com П. А. Пех
Кандидат техычних наук, доцент, завщувач кафедри*
E-mail: pekh_petro@mail.ru К. В. Мельник Кандидат техычних наук, доцент* E-mail: ekaterinamelnik@gmail.com Н. В. Багн юк Кандидат техычних наук, доцент* E-mail: bagnjuk_n@rambler.ru О. К. Жигаревич Асистент* E-mail: oz_lutsk@mail.ru *Кафедра комп'ютерноТ шженерп Луцький нацюнальний техшчний уыверситет вул. Львiвська, 75, м. Луцьк, УкраТна, 43018
1. Вступ
Завдяки зростаючш продуктивност комп'ютер-ного обладнання вже вперше введет технологи вiр-туалiзащi ставали ефективним способом тдвищення коефвдента використання апаратних ресурив. Так, завдяки запуску багатоканальноi операцiйноi системи на однш фiзичнiй машиш (комп'ютер^ ставало оче-видним тдвищення не пльки використання ресурав, але й скорочення витрат на управлшня i отримання б^ьш високоi продуктивносп i надiйностi, в порiвнян-ш iз роботою одноканальноi операцiйноi системи. На сьогодш традицiйнi розподiленi додатки можуть бути в^ьно розгорнутi на подiбнiй платформi, працюючи легко i прозоро за рахунок високопродуктивних со-кетiв [1, 2]. Однак при розгортанш деяких мережевих додаткiв штенсивного використання, наприклад, таких як iнтернет-серверiв, файлових мережевих систем, ефектившсть комунiкацii мiж доменами i сьогодш викликае серйознi проблеми.
Хоча бшьшшть МВМ-машин, наприклад, TaKi як Xen [3], пiдтримують в сво!й po6oTi деякi методи для забезпечення вимог зв'язку мiж доменами, з забезпе-ченням двостороннього зв'язку мiж доменами. Один i3 цих зв'язкiв заснований на протоколi TCP/IP, а ш-ший е новим протоколом, що називаеться Хеп-сокетом [4], який i використовуеться для отримання високо! пропускно! здaтностi. Всi вони потребують МВМ для перехоплювати комунiкaцii, що i призводить до зниження продуктивност i пiдвищення часу затримки. Таким чином, протокол мiж доменами зв'язку стае основним вузьким мкцем системи при розгортанш роботи деяких додатюв з штенсивною обробкою даних на МВМ-машинах. Наприклад, пропускна здaтнiсть Хеп-сокепв становить тiльки 130 Мбiт, а це набагато нижче, шж емшсть гiгaбiтних мереж Ethernet. Ця ситуащя, ускладнюеться в основному через низьку продуктившсть, обумовлену роботою стека TCP/IP i частотою посторiнковоi передaчi шформацп пiд час сеансу зв'язку.
©
2. Аналiз лкературних даних та постановка проблеми
1снують деякi публiкацii, яю розглядають усунен-ня непотрiбних nepeBipoK пакепв з метою отримання пpoпускнoi здaтнoстi пepeдaчi даних до 3310 Мби/с [5]. I хоча в цш poбoтi описано удосконалення Хеп-сокета з метою отримати пропускну здатшсть 9295 Мбiт/с, однак Хеп-сокет являеться oднoстopoннiм тунельним протоколом, тобто, в той же час, можна сказати, в кому-шкацп е пльки один домен для вiдпpaвки повщомлен-ня i один домен для його отримання. I коли виникае потреба з двох стopiн вщправити пакет, то мepeжeвi додатки повинш створювати iнший сокет. Це при-зводить до зростання склaднoстi використання Хеп-сокета. В pядi роби [6, 7] (з Хеп-петлею), [8] (Х-шля-хом), якi в свoiх дoслiджeннях взяли за основу анало-гiчнi спopiднeнi побудови з застосуванням Хеп-сокета, досягли удосконалення двoхстopoнньoi сумшност через дiючi канали зв'язку до мережевого стека. Одже, в« описаш вище пiдхoди вoлoдiють меншою пропускною здaтнiстю в пopiвняннi з UNIX IPC i не досягають спо-дiвaних oчiкувaнь.
Для того, щоб передавати iнфopмaцiю на довгому шляху пepeдaчi через складне мережеве середовище, Роберт Еллioт Кан розробив i втiлив у використання TCP/IP протокол. 1нформащя повинна спочатку помь ститися в буфер сокета, який повинен бути вид^ений для протоколу TCP/IP. Дaлi вона повинна бути пере-будована в пакет даних, перед тим як користувач вщ-править повщомлення. Тiльки тoдi TCP/IP обчислить контрольну суму створеного пакета даних. Шсля цьо-го, NIC направляе пакет даних до мepeжi за допомогою DMA. Якщо користувач хоче отримати повщомлення з мереж^ TCP/IP повинен розпакувати пакет даних i пepeвipити контрольну суму, щоб переконатися, що по-вiдoмлeння було прийняте правильно. Якщо виявлено, що трапилося що-небудь не так тд час цього процесу, вщповщне повщомлення буде вiдпpaвлeнo знову. Описаний експеримент доводить, що не шнуе, наприклад, окремого бiтa даних для випадку, коли допущено необ-хщшстю передати пoвiдoмлeння на вiдстaнь 90 кшо-мeтpiв через ускладнену мережу.
Вся надшшсть пepeдaчi даних опираеться на строго точну i складну пepeвipку вiдiслaнoгo пакета. На недостаток, в той час як дана технолопя забезпечуе високу надшшсть, цей же процес зумовлюе дoдaткoвi витрати i знижае показник висoкoi пpoдуктивнoстi. Згiднo з aнaлiзoм, проробленим в робоп [9], процедура процесу TCP/IP займае до 15 % процесорного часу CPU, а котювання даних i здшснення пepeвipки пакета буде забирати навиь до 34 % процесорного часу CPU. В робой [10] було пpoaнaлiзoвaнo ефект впливу TCP/IP на операцшну систему. Система зму-шена жертвувати 14 % влaснoi продуктивноси для упpaвлiння буфером даних, а вщповщш драйвери займатимуть 20 % процесорного часу CPU, в той час як процедура процесу TCP/IP займае лише 26 % про-цесорного часу CPU.
В poбoтi [9] також здшснюеться aнaлiз заванта-ження пам'яп, обумовлене TCP/IP. У цш poбoтi ops-пам'ять може бути розд^ена згiднo призначення на три типи: читання даних з простору користувача в про-CTip ядра, яка обумовлюе 0,1 % накладних витрат; за-пис даних в буфер сокета, який зумовлюе 1.1 % наклад-
них витрат; i читання та надсилання даних вщ NIC, як разом обумовлюють до 2,5 % накладних витрат.
Роблячи тдсумок цих експерименпв, можна зро-бити висновок, що причиною спаду продуктивност роботи TCP/IP е ускладнення управлшня буфером, пepeвipки даних та необгрунтоваш рамки керування, однак не часто ops-пам'ять. Процедура кoпiювaння даних у фiзичнiй мaшинi е досить надшною i можна отримати високу продуктившсть пepeдaчi даних за рахунок усунення процедури пepeвipки даних i скоро-чення шляху проходу даних.
3. Мета i завдання дослщження
Метою дано! роботи ставиться розробка i мож-ливiсть застосування високопродуктивного мехашз-му мiждоменного комушкацшного зв'язку, названого ком-сокетом, який базуеться на механiзмi комунiкацii зi стльною (роздiлювальною) пам'яттю.
Використання МПП заметь асинхронного повь домлення в процеа доставки мае сприяти зниженню часу затримки ком-сокета. Передбачаеться, що ме-хашзм використання спiльноi пам'ятi не пльки мае скорочувати час копи пам'яп, але i дозволяти уни-кати накладних витрат, обумовлених посторшковою пропускною здатнiстю. Перспективним е те, що МВМ не буде потрiбно перехоплювати в комунiкацii мiж доменами, що також дозволить уникнути накладних витрат, спричинених МВМ-викликом i спричинить тдвищенню продуктивностi.
З iншоi сторони актуальним е те, що ком-сокет вщповщае стандарту сокепв Берклi. Це говорить про те, що програмкт може легко його використовувати. Прототип ком-сокета реалiзований на базi процесорiв х86 МВМ.
Завданнями дослiдження, вирiшення яких пред-ставляеться доцiльним для досягнення ще! мети, об-рано:
- створити ком-сокет з використанням стльно! пам'ятг,
- запрограмувати необхiднi програмш структури для забезпечення функцiонування ком-сокета;
- здшснити реалiзацiю ком-сокета;
- провести порiвняльну характеристику його роботи з шшими видами зв'язку, враховуючи час затримки та продуктившсть.
4. Розробка та cnoci6 реалiзащ¡ ком-сокета
Стандартний сокетий iнтepфeйс забезпечуеться ком-сокетом, яким користувач може так же само легко використовуватися, як i при використанш IPC UNIX. То ж зараз буде описано детальну шформащю про принципи проектування ком-сокета та його впрова-дження, включаючи рамки роботи, управлшня буфером, оповщення про повщомлення i iншe.
Створення TCP/IP включае в себе умову забезпе-чення пpaвильнoстi та надшност пepeдaчi даних на ускладненш мepeжi. Таким чином, в пpoтoкoлi TCP/IP е дeякi усклaднeнi i чaсoмiсткi oпepaцii, якi було проа-нaлiзoвaнo в попередньому poздiлi. Можна припусти-ти, що нiякoi помилки не вщбуваеться при кoпiювaннi
даних у фiзичнiй машиш, оскiльки весь цей процес вщбуваеться в стабшьному середовищi i високiй на-дшносп перевiрки ECC пaм'ятi. Однак, без будь-яких модифжацш це призведе до низько! продуктивностi в умовах використання TCP/IP протоколiв у мiждо-менному зв'язку. Таким чином, для того, щоб отримати високу продуктившсть, ком-сокети повиннi усунути непотрiбнi витрати часу i перевiрку пакепв даних та спростити упрaвлiння стеком.
Традицшна мiждоменнa комунiкaцiя, яка базуеть-ся на MBM, повинна i часто здiйснювaти MBM-вик-лик. Проте добре вщомо, що MBM-виклик е причиною частих операцш TLB-виключень, як забруднюють L2-кеш, переповнюючи р1релтю i так дaлi. Все це призведе до прямих i непрямих затрат як нaдaлi негативно впливають на продуктившсть роботи додатюв як в режимi виконання користувача, так i в режимi виконання ядра. Таким чином, здшснення MBM-ви-клику повинно бути як можна меншим, i нaвiть з уник-ненням його тд час передaчi даних.
Однак, як вщомо, досить важко видшити кiлькa по-слiдовних сторшок в пaм'ятi, якщо оперaцiйнa система працюе протягом тривалого часу, тому що це виклика-тиме часп swap-операцп i навiть може призводити до фрагментацп пaм'ятi. То ж ще один важливий принцип дизайну сом-сокета направлений на зменшення часто-ти вид^ення пaм'ятi, нaскiльки це можливо реaлiзувa-ти, щоб зменшити вплив на систему пам'яп в щлому. У той же час, штерфейс ком-сокета повинен слiдувaти Berkeley-стандарт сокета, щоб зробити його зручним для використання програмктами-розробниками.
Рис. 1. Арх^ектура ком-сокета
Рис. 1 показуе архитектуру ком-сокета. Програмшт може використовувати штерфейс ком-сокета для вза-емодii з шшими доменами. В кожному домеш е маршрутизатор, який визначае шлях i домен-одержувач для вщправки повiдомлення. Якщо домен вiдправляе повщомлення самому собi, то маршрутизатор переда-ватиме повiдомлення до вiдповiдного сокета, i якщо цiльовими е iншi домени, то маршрутизатор скопiюе поввдомлення в буфер, що вiдповiдае вщповщному домену i побудуе вiдповiдну структуру даних для опису повщомлення, поклавши ii в чергу цiльового домена-приймача. Якщо щльового домена не кнуе,
маршрутизатор буде вiдкидaти повiдомлення i повер-тае код помилки для додатка. Для забезпечення умови iзоляцii та зaкритостi доступу мiж доменами, кожен домен може читати пльки свiй доступний йому буфер i записувати в буфери шших доменiв.
В кожному домеш е власний daemon для скануван-ня черги приймача, виявлення i отримання шформацп про опис повщомлення, з якого вiн i отримуе адресу поввдомлення в пaм'ятi. В опис структури поввдомлен-ня подаеться шформащя про вiдпрaвникa поввдом-лення, приймача i все iнше, яка докладно буде описана нижче в цьому роздШ публжацп.
Вiдповiдний буфер стльно! пaм'ятi використову-еться ком-сокетом для передaчi даних. Вiн резер-вуеться MBM безпосередньо при стари операцшно! системи, i вона фжсуе фiзичну адресу цього буфера в адресний проспр через MBM-виклик. Кожен домен мае власний буфер який е доступним шшим доменам, в який вони можуть здшснювати пльки запис, i який може пльки зчитуватися власним доменом.
Як показано на рис. 2, кожен такий ввдповвдний домену буфер длиться на блоки по 8 КБ, яю помiченi бiт-кaртою вiдобрaження. Коли домен посилае деяке поввдомлення, вiн повинен перш за все запросити блок для того, щоб розмктити його в нього i маскувати ввд-поввдний бiт в бiт-кaртi вщображення, щоб вказати, що блок використовуеться (зайнятий), а поим розмктити шформащю опису повiдомлення в черзi прийому для вщповщного домена i, при необхвдносп, повiдомити про це домен-приймач. Приймаючий daemon повинен сканувати власну чергу прийому повщомлень з метою отримати 1нформац1ю опису пов1домлення, за допомогою яко! вiн повинен отримати розмiр повiдомлення, адресу пaм'ятi та шшу корисну iнформaцiю про повiдомлення прийому. Дaлi вiн повинен побудувати вщповщну структуру i роз-мiстити його у ввдповвдний список отримувача сокета, з якого додаток i отримае повщомлення. Пiсля того, як повщомлення буде прочитане, ком-сокет очистить вщповщний бiт повiдом-лення в бгг-кари вiдобрaження для звiльнення мiсця пам'ять
Через вищенаведений опис можна зрозумии, що немае MBM-викликiв пiд час передaчi даних, а тiльки потрiбно здiйснити всього два рази котювання даних: перший раз - з простору ко-ристувaчa-вiдпрaвникa до вщповщно! спiльноi пaм'ятi, а другий - з вщповщно! пaм'ятi у про-стiр користувача-приймача.
Для того щоб зменшити складшсть програму-вання i пiдтримки програмного стилю, ком-со-кет використовуе ту ж структуру адреси, що i IPv4-формaт. Якщо адресою з'еднання е 192.168.0.0, то вона е закритою адресою, а IP-адреса кожного домена мктить власний щентифжатор домена зб^ьшений на 2. Наприклад, якщо вдентифжатор домена рiвний 3, то вiдповiднa IP-адреса для нього буде 192.168.0.5. По аналоги як i IPv4, адреса 192.168.0.255 використову-еться для мовлення. Номер порта використовуеться операцшною системою для того, щоб вщокремити рiзнi додатки з метою забезпечення неповторноси ввд-правки та отримання повiдомлень.
Оповщення про надходження повiдомлення здiйс-нюеться в наступному порядку. 6 двi схеми, яю мо-
жуть бути використаш в якост мехатзму oпoвiщeння пoвiдoмлeння: перша схема використовуе таймер для сканування буфера з метою пepeвipити наявшсть по-вщомлень, що oчiкують обробки; iншa - використовуе дозвш на виконання завдання пepeвipки буфера, коли здiйснюеться кожне переривання. Ва вони або спри-чиняють великий час затримки, або призводять до високого завантаження CPU. 3i сторони цих причин ком-сокет використовуе мiжпpoцeсopнi-пepepивaння (МПП) для того, щоб повщомити щльовий домен про надходження поввдомлення для нього.
OxffaOOOOOO OxffaSOOOOO OxffbOOOOOO
Domain 0 Domain 1 Domain 2
0xffa7fffff Oxffaffffff 0xffb7fffff
Рис. 2. Арх^ектура пам'ятi у вiдповiдностi до домена
МПП вщправляеться з вiдправкою повщомлення i цiльовий домен буде сплановувати daemon прийому для аналiзу буфера повщомлень i отримання ввдсла-ного повщомлення. В зв'язку з високою значимiстю МПП не могло бути згенерованим тсля вiдправки повiдомлення. Ком-сокет використовуе тег, щоб вщ-кривати/закривати через прапор статусу прийомний daemon. Якщо daemon в цю мить обробляе повщомлен-ня, то нове повщомлення буде оброблено автоматично. У цш ситуацп, немае необхiдностi в МПП. В шшому випадку, потрiбно вiдправити МПП до домена прийому з метою повщомити приймач про явне прибуття нового повщомлення.
Одшею з важливих структур даних ком-сокета е його сокетна структура тд назвою comsock. Саме ü та пов'язанi з нею структури наведено нижче.
struct com_sock
{
struct sock sk; struct com_addr dest; struct com_addr sour; struct com_skb_head skb_head;
spinlock_t lock; };
struct com_skb
{
struct com_skb *next; struct com_buf *msg; int port; int offset;
int len; };
struct com_rcv_msg
{
int msg_len; struct com_addr sour; int dest_port; int flags; char type;
struct com_buff msg_data;
int msg_num; };
struct domain_buff_control
{
int start;
int msg_index[TAB_ENTRYS]; spinlock_t buf_lock; long empty[TAB_ENTRYS/64]; spinlock_t recv_lock; int end;
struct com_recv_msg msg [TAB_ENTRYS]; };
В структуру comsock включена також i стандартна сокетна структура sock, а також поля щльово! адре-си одержувача, адреси вщправника та список повь домлень. Список поввдомлень будуеться за зразком структури comskb. Для того щоб забезпечити синхро-тзащю, структура comsock використовуе спш-блоку-вання (параметр типу spinlock t). Тип повщомлення, довжина, зсув, адреса i деяка шша корисна шформа-цiя, - все вложено в структуру comskb.
Проста дiаграма потоюв даних подана на рис. 3. Коли користувач реалiзуе системний виклик send()/ write() з попаданням в ядро, вщправник повинен на-самперед просканувати бггову карту bit-map щльового домена, щоб отримати в^ьний блок. Щоб скотювати данi безпосередньо в спiльний буфер пам'ят цiльового домена використовуеться функщя copy_from_iovc(). Якщо цiльовий домен не обробляе повщомлення, вiдправнику також необхщно вiдправити МПП до нього, щоб повщомити його про явне надходження поввдомлення. Приймаючий daemon здiйснюе сканування списку повщомлень для здшснення обробки поввдомлення, що надiйшло, i пометить його у skb-спи-сок ввдповвдного цiльового сокета. Коли користувач застосовуе системний виклик receive()/read()з попаданням в ядро, операцшна система буде використо-вувати функщю get_msg_from_skb(), щоб отримати по-вiдомлення iз skb-списку, а потiм за допомогою функцп copy_to_iovc() скопiюе данi безпосередньо в проспр користувача. Пiсля цього операцшна система очистить вщповщний би в бiтовiй картi bit-map, щоб звшьнити блок.
Можна зробити висновок з усього прокоментова-ного вище процесу, що е тiльки два рази котювання даних з одного домену в шшш, i немае необхщносп у МВМ-виклику протягом усього цього процесу.
SERVER
sockfd=socket(AF_COM, ...);
bind(sockfd, ...); listen(sockfd, ...);
recvsock=accept(sockfd, ...);
read(recvsock, ...);
write(recvsockfd, ...);
close(recvsock); CLIENT
sockfd=socket(AF_COM, ...);
connect(sockfd, ...); write(sockfd, ...);
read(sockfd, ...); close(sockfd, ...);
4. Обговорення результатiв дослщжень ком-сокета
Далi можна попробувати реалiзувати прототип ком-сокета на 6a3i системи x86 MBM яка може запуска-ти юлька примiрникiв операцiйноï системи в один i той же час без додаткових продуктивних затрат. Ядро ви-дшяе ресурси для операцiйноï системи i захищае ïï ввд несанкцiонованого доступу iнших користувачiв. Таке мжроядро вiдтворюe хорошу продуктивнiсть i з ним одночасно можуть працювати багато шших серверiв, що базуються на ядернiй основi, проявляючи, як i тра-дицiйнi MBM, гнучюсть i широкомасштабнiсть роботи.
Рис. 3. Дiаграма потоку даних для ком-сокета
Рис. 4. Ком-сокет, UNIX IPC та порiвняння продуктивное^ копiювання пам'ят
Ця iдея досить добре тдходить для cloud-комп'ютер-ноï обробки даних. У цьому дослщжент для тестування продуктивносп ком-сокета використано двохпроцесор-ний AMD Opteron сервер DELL T605 з 16 ГБ DRAM. Ви-явлено, що ком-сокет мае бшьш високу продуктившсть у порiвняннi з UNIX IPC i досягае очжуваних резуль-татiв. Рис. 4 показуе результати дослщжень ком-сокета, UNIX IPC та порiвняння продуктивностi копiювання пам'ят! В данiй роботi не порiвнюються результати дослiджень ком-сокета з результатами Хеп-сокета, тому що Хеп-сокет i Х-шлях мають бiльш низьку продуктившсть зпдно наведених лiтературних даних у порiвняннi з UNIX IPC [4, 8]. То ж, осюльки немае MBM-перехо-плення при обробщ комунiкацiï, ком-сокет також отри-маете високу продуктившсть в шшому MBMi.
По-перше, порiвняемо пропускну здатнiсть кожного протоколу зв'язку, включаючи, UNIX IPC зв'язок мiж доменами, Loopback i ком-сокет. Щоб продемонструвати високий рiвень комушкацп, можна також перевiрити швидюсть копiювання пам'ятi. У цьому експеримент вiдправляетьсч 1GB даних на шший домен для розмiру повiдомлення в дiапазонi вiд 1 до 512 Кб. Чим менше часу (рис. 4) використовуеться для кожного протоколу, тим бшьш високу пропускну здатшсть вш виявляе в ро-бот1 Як видно з рисунка, смуга пропускання ком-сокета значно вища, шж в iнших протоколах у випадках, коли блок поввдомлень е об'емно малим. Це проявляеться тому, що ком-сокет спрощуе управлшня буфером. У той же час, висока продуктившсть видшеного буфера використовуеться ком-сокетом, щоб уникнути виклик kmalloc() i щоб звшьнитися ввд зайвоï операцп, яка за-ймае вiдповiдний промiжок часу. Використання МПП дозволяе уникнути MBM-виклику при ввдправленш
поввдомлення, який все-таки використовуеться Xen-со-кетом [5], кожен раз. Це робить ком-сокет бшьш простим i ефективним.
За допомогою лиературних даних [7, 8] та експе-риментальних вимiрювань здiйснено порiвняння часу затримки при встановленнi операцп з'еднання для кожного виду протоколу. Ком-сокет володiе меншим часом затримки, (50 с.) шж шший протокол (Xen [8] - 210 с., Loopback - 71 с.), за винятком UNIX IPC (21 с.), i е бшьш ефективним, шж iншi протоколи. Це проявляеться тому, що, при встановленш з'еднання, ком-сокет повинен ввд-правити переривання МПП на сервер i сервер також мае ввдправити МПП клiенту. Осюльки операщя МПП ви-магае ввдповвдних часових затрат, то ком-сокет i володiе дещо вищим часом затримки в порiвняннi з UNIX IPC.
5. Висновки
В робоп створено i застосовано мехашзм зв'язку, ком-сокет, що використовуе мiжпроцесорне перери-
вання (МПП) для синхрошзацп i усунення деяких некорисних перевiрок пакепв при передачi даних. За-програмовано робочi структури для функцiонування ком-сокета зi спiльним використанням пам'ятi (shared memory) для скорочення часу котювання даних. Здшс-нено також порiвняльну характеристику параметрiв часу затримки та продуктивность Виявлено, що ком-со-кет володiе меншим часом затримки та бшьшою про-дуктивнiстю порiвняно з шшими видами зв'язку, в тому чи^ i з UNIX IPC.
Хоча ком-сокет демонструе високу продуктившсть, однак вш не тдтримуе повно'1 бiнарноï сумiсностi, тобто додаток не може використовувати ком-сокет безпосе-редньо, без певноï модифiкацiï. З iншого боку, ком-со-кет не пiдтримуе асинхронний мехашзм, а потребуе здшснювати сканування списку поввдомлень з метою виявлення в ньому нового, що надходить у випадку, коли користувач хоче отримати нове поввдомлення. Таким чином, виходячи з даноï роботи було б корисно ввдтворити ком-сокет з тдтримкою бiнарноï сумшносп та асинхронного механiзму.
Лiтература
1. Мельник, В. М. Вплив высокопродуктивных соке™ на штенсившсть обробки даних [Текст] / В. М. Мельник, Н. В. Багнюк, K. В. Мельник // ScienceRise. - 2015. - Т. 6, № 2 (11). - С. 38-48. doi: 10.15587/2313-8416.2015.44380
2. Melnyk, V. M. High production of java sockets for health clouds in science [Текст] / V. M. Melnyk, O. K. Zhygarevich, K. V. Mel-nyk // Engineering Software. - 2014. - Vol. 19, Issue 3. - P. 36-40.
3. Barham, P. Xen and the art of virtualization [Text] / P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, A. Warfield //In Proceedings of the nineteenth ACM symposium on Operating systems principles. ACM, 2003. -P. 164-177.
4. Zhang, X. Xen-socket: A high-throughput interdomain transport for virtual machines [Text] / X. Zhang, S. McIntosh, P. Rohatgi, J. Griffin // Lecture Notes in Computer Science, 2007. - P. 184-203. doi: 10.1007/978-3-540-76778-7_10
5. Menon, A. Optimizing network virtualization in Xen [Text] / A. Menon, A. L. Cox, W. Zwaenepoel // In Proceedings of the annual conference on USENIX'06 Annual Technical Conference: USENIX Association, 2006. - P. 2.
6. Burtsev, A. Fido: Fast intervirtual-machine communication for enterprise appliances [Text] / A. Burtsev, K. Srinivasan, P. Radhakrishnan, L. N. Bairavasundaram, K. Voruganti, G. R. Goodson // In Proceedings of the 2009 conference on USENIX Annual technical conference: USENIX Association, 2009. - P. 25-25.
7. Wang, J. Xen-loop: a transparent high performance inter-vm network loopback [Text] / J. Wang, K. L. Wright, K. Gopalan // In Proceedings of the 17-th international symposium on High performance distributed computing: ACM, 2008. - P. 109-118. doi: 10.1145/1383422.1383437
8. Kim, K. Interdomain socket communications supporting high performance and full binary compatibility on Xen [Text] / K. Kim, C. Kim, S. I. Jung, H. S. Shin, J. S. Kim // In Proceedings of the fourth ACM SIGPLAN / SIGOPS international conference on Virtual execution environments, 2008. - P. 11-20. doi: 10.1145/1346256.1346259
9. Foong, A. P. TCP performance revisited [Text] / A. P. Foong, T. R. Huff, H. H. Hum, J. R. Patwardhan, G. J. Regnier // IEEE International Symposium on Performance Analysis of Systems and Software. ISPASS 2003, 2003. - P. 70-79. doi: 10.1109/ ispass.2003.1190234
10. Minturn, D. Addressing TCP/IP processing challenges using the IA and IXP processors [Text] / D. Minturn, G. Regnier, J. Krueger, R. Iyer, S. Makineni. // Intel Technology Journal. - 2003. - Vol. 7, Issue 4. - P. 39-50.
