Проект на софтуерен продукт за предаване на данни и глас между компютърни мрежи зад мрежов преобразувател на адреси (nat)
Изтегляне 88.55 Kb.
|
- Навигация на страницата:
- Ключови думи
- Вход и изход на звук и програмното приложение
- ЗА СЪСТАВНИТЕ ЕЛЕМЕНТИ В ДЕТАЙЛИ Методите за преодоляване на NAT
- Speex вокодерът
- ЛИТЕРАТУРА [1]
ГОДИШНИК НА ТЕХНИЧЕСКИ УНИВЕРСИТЕТ – ВАРНА, 2007 г. ПРОЕКТ НА СОФТУЕРЕН ПРОДУКТ ЗА ПРЕДАВАНЕ НА ДАННИ И ГЛАС МЕЖДУ КОМПЮТЪРНИ МРЕЖИ ЗАД МРЕЖОВ ПРЕОБРАЗУВАТЕЛ НА АДРЕСИ (NAT) Александър Николаев Павлов* *Технически университет – Варна, ул.”Студентска” №1, e-mail: new_project@abv.bg Резюме: Описан е проект на програмно приложение за операционна система Windows, служещо за обмен на данни и глас по интернет. Засегнат е проблема, и е дадено евентуално решение, за осъществяване на директна връзка между потребители намиращи в компютърни мрежи зад мрежови преобразуватели на адреси (NAT). Използван е вокодерът с отворен код Speex, базиран на CELP кодиране, позволяващ десетократна компресия на потока в нормален режим на работа. За взаимодействие със звуковата карта на компютъра се използва интерфейсът DirectSound. Направени са ориентировъчни изчисления на времезакъснението даващи обещаващи резултати. Показани са и клас диаграми и блокова схема на приложението. Макар и проект 40% от системата вече е реализирана и функционира. Ключови думи: NAT, STUN, STUNT, вокодер, Speex, CELP, предаване на глас, обмен на данни, приложение програмно, Transfiler. ВЪВЕДЕНИЕ
В днешно време компютрите са мултифункционални устройства, чрез които потребителите извършват разнородни задачи, благодарение на програмното осигуряване. След като Интернет стана достъпна свързваща среда за много хора, възникна стремежа за предаване на глас по тази среда, подобно на опитите за предаване на глас по електрозахранващата мрежа в миналото. За щастие Интернет телефонията стана факт далеч преди да се зароди идеята за настоящия проект. Оказва се обаче, че с нарастване на интернет потребителите броят на IP адресите ограничен от IPv4 до 4’294’967’295 (232 - 1) става недостатъчен. Решението на този проблем е използването на мрежов преобразувател на адреси (network address translator - NAT), устройство позволяващо множество компютри да използват един IP адрес за достъп до глобалната мрежа. За множество програмни приложения това не е проблем, а за някои потребители дори е предимство тъй като “отвън” единствения видим адрес е този на NAT-а. Тук е мястото да се споменат и т.нар. огнени стени (firewall), които също осигуряват защита на потребителя. И двете обаче, подобно на трансформаторите в идеята за глас по електрозахранването, внасят ограничения при реализацията на проектите. NAT-овете правят невъзможна простичката директна връзка между две мрежови приложения (т.нар. peer-to-peer), тъй като приложение зад NAT няма глобално достъпен IP адрес и следователно не може да бъде сървър за осъществяване на връзката. Възможни решения са:
Гласовата комуникация от своя страна изисква директна връзка с цел минимално закъснение. Ако се приеме най-лошият сценарий, при който участниците са в две различни мрежи, всяка от които зад собствен NAT, изглежда че задачата е неосъществима. За щастие преобразувателят на адреси е, така да се каже, софтуерен продукт далеч по-податлив на измама от “хардуерния” трансформатор. Съществуват технологии за “пробиване” на NAT-ове, две от които ще бъдат използвани в настоящия проект. STUN (Simple Traversal of UDP through NATs) е мрежов протокол позволяващ на клиент зад един или множество NAT да установи публично видимия си адрес, типа на NAT-а зад който е и съответствието на локалните портове с интернет портовете асоциирани от адресния преобразувател. Тази информация се използва за осъществяване на UDP комуникация между потребителите намиращи се зад два различни NAT-а. Протокола е дефиниран в RFC 3489 (http://tools.ietf.org/html/rfc3489). STUNT (Simple Traversal of UDP through NATs and TCP too) разширява STUN с функционалност за TCP комуникации. Това е протокол позволяващ на приложения активирани зад NAT да определят външните IP адрес и порт, условията за филтриране на пакети и различните timeout времена свързани с TCP връзките през NAT-а. Осъществяването на peer-to-peer TCP връзки между потребители зад NAT е малко по-сложно в сравнение с UDP, но на ниво протокол двете техники си приличат много.
Предаването на глас по ограничен по капацитет канал интуитивно предполага, а в случаите на малка честотна лента се налага, използването на компресия. В случаите на гласови приложения апаратът (или програмната библиотека) се нарича “вокодер” (voice coder). Избраният за настоящия проект вокодер се нарича Speex 1.2 и представлява написана на С програмна библиотека с отворен код позволяваща приблизително десетократна компресия на гласовата информация базирана на CELP кодиране.
След като е изяснено кодирането, предаването и декодирането, остава да се осигури взаимодействието с потребителя. Избран е The Microsoft® DirectSound® application programming interface (API), който е аудио частта на DirectX®. DirectSound осигурява миксиране с малко закъснение, хардуерно ускоряване, и директен достъп до звуковото устройство. От друга страна позволява на разработчика да не се грижи за възможностите на конкретното звуково устройство. DirectSound API сам определя кои операции да се извършат хардуерно и кои да бъдат софтуерно емулирани. ЗА СЪСТАВНИТЕ ЕЛЕМЕНТИ В ДЕТАЙЛИ
На кратко основен метод за осъществяване на директна връзка през NAT-ове е чрез т.нар. посредник. Сървърно приложение е активно на глобален IP адрес и служи за предаване на информация между клиентите зад преобразувателите на адреси. Клиентите желаещи да осъществят директна връзка помежду си, първо се свързват със сървъра. Той от своя страна предава към всеки от тях информацията за глобалния адрес и порта използван от NAT-а на другия за осъществяване на връзката до сървъра. След като разполагат с тези данни, клиентите започват да си изпращат пакети директно, без участието на сървъра. Естествено е началните пакети да не достигнат до целта си тъй като NAT-овете ще ги отхвърлят. Но на следващите, преобразувателя започва да гледа като отговор на изпратените пакети, пропуска ги и директната връзка е осъществена.   
фиг. 1
По UDP протокол описана схема работи сравнително леко, поради природата на несвързан протокол. На фиг.2 е показана блокова диаграма за определяне вида на NAT-a или firewall-а, зад който е потребителя. STUN протокола е известно че не работи със симетричните NAT и firewall, които преобразуват както вътрешните така и външните адреси. 
фиг. 2
По TCP протокол нещата са малко по-сложни, тъй като той е свързан протокол. За щастие създателите на мрежовите програмни библиотеки са осигурили възможността няколко сокета (обекти служещи за осъществяване на мрежова връзка в програмните приложения) да използват един и същи порт. По този начин, както е показано на фиг.3, всяко приложение отваря три сокета на един и същ порт. С първия се свързва към сървъра посредник, а с втория “подслушва” за връзка от абоната с който желае да осъществи директна връзка. След получаване на данните за отсрещната страна всеки от двамата започва опити да се свърже с другия. За съжаление вероятността за успех по статистически наблюдения клони към 50%. 
фиг. 3
На кратко основните му характеристики са:
Speex е базиран на CELP, което е абревиатура за Code Excited Linear Prediction(Линейно предсказване с кодово възбуждане).CELP се основава на три идеи: а. Използването на методите на линейното предсказване за моделиране на гласовия тракт; б. Използването на (адаптивна и фиксирана) кодова книга за възбуждане на модела на гласовия тракт; в. Търсене осъществено в затворен цикъл в “област с оценка на възприетото” (“perceptually weighted domain”); Нивото на компресия и скоростта на потока е както следва: - при fs =8 kHz, един кадър от 20 ms се кодира в 28 байта (2) V1 = 28 B/frame * 50 frame/s * 8bit = 11200 bps - при fs =16 kHz, един кадър от 20 ms се кодира в 42 байта (3) V2 = 42 B/frame * 50 frame/s * 8bit = 16800 bps Ако се окаже, че тези стойности не са достатъчно ниски може да се използва променлива скорост на потока осигуряваща различна дължина на кодирания пакет в зависимост от фрагмента подлежащ на кодиране.
DirectSound поддържа два вида буфери за възпроизвеждане: статичен и поточен (stream buffer). Тъй като статичният буфер се използва за директно зареждане на малки по дължина отрязъци звук (4-5 сек. ) и използва сравнително много памет е неприложим за настоящия проект. Speex вокодерът изисква отрязъци от по 20 ms които да кодира, или връща 20 ms декодирани фрагменти. По тази причина се използват два кръгови поточни буфера с дължина 60 ms всеки – един за запис и един за възпроизвеждане. DirectSound API позволява на разработчика да изиска получаване на съобщение всеки път щом курсорите за запис или възпроизвеждане преминат дадена позиция в съответния буфер. Чрез три позиции във всеки буфер, на 20 ms разстояние, се осигурява координираната работа за прихващането на звук, кодирането, декодирането и възпроизвеждането му. 
фиг. 4
Използването на вокодер неминуемо внася закъснение в предаването. За Speex това закъснение е равно на продължителността на кодирания кадър (frame) добавено към известно количество “look-ahead” нужно за пресмятането на кадъра. За теснолентов режим (8 kHz) закъснението е 30ms, докато за широколентовия режим (16 kHz) закъснението е 34 ms. В тези времена не се отчита времето нужно на процесора за кодиране или декодиране на кадъра. Освен тези времена трябва да се има предвид допълнителното закъснение от 20 ms при възпроизвеждане, което осигурява стабилната работа на буфера и дава нужното време на приложението да предположи евентуалното съдържанието на пропуснат пакет. Обобщено:
По формула (1) сумата на константните величини дава 88 ms, което позволява сравнително голямо закъснение по мрежата, особено отчитайки бързодействието на съвременните процесори, преди да се достигне критичната граница.
фиг. 5
На фиг. 6 е показана диаграма на С++ класове служещи за обезпечаването на мрежовите връзки. 
фиг. 6
SockHold е координиращият клас съдържащ списъци със слушащи сокети и сокети служещи за обмен на данни (в това число и глас). SockHold се грижи и за потребителския интерфейс на ниво обмен на писмени съобщения. Изброяването Purposes служи за дефиниране на поле на класа DataSocketEx чрез което по време на работа може да се определи за какво служи даденият обект текущия момент. DataSocket и неговите производни имат полета с манипулатори към файлове, редица двоични флагове и сокети служещи за целите на обмяна на съобщения, глас и данни, последните под формата на файлове. Функционалността на този клас е завършена с предоставянето на потребителски интерфейс за избор на изпращан и приеман файл. Важно е да се отбележи, че служебните съобщения се предават по връзката за писмен диалог между потребителите, понеже тя е най-слабо уплътнена. За целите на защитата са въведени методите CheckReceived() и CheckInserted(), които не позволяват на потребителя да въведе служебни команди, или пък последните да бъдат визуализирани на ниво текст.
Фиг. 7 показва йерархията на класове обвиващи функционалността на DirectSound и класа SpeexCodec логически свързан с тях. 
фиг. 7
SoundBase е абстрактен клас, дефиниращ общите променливи и базовата функционалност за прихващане и възпроизвеждане на звук. В неговите преки наследници са обособени и реализирани тези функционалности. MicListener и SoundMaker могат да се ползват в различни приложени и са независими от задачата която се решава. Различните техни приложения се обособяват в специализираните класове MicListenerEx и SoundMakerEx, които в конкретния случай са натоварени със задачите по кодиране и декодиране на гласовите данни. За целта всеки от тях създава инстанция на класа SpeexCodec и подава отрязъци от по 20 ms на нужния метод Encode() или Decode().
фиг. 8
Приложението използва програмния интерфейс Win32 API, в частност WinSock 1.1, DirectX8, файловата система на Windows OS, както неговия графичен интерфейс. Съдейки, че Windows все още е най-разпространената ОС това не е проблем, а по отношение на бързодействието тази тясна специализация е добра, тъй като се използват директно ресурси на системата. На фиг. 8 е демонстрирана визията на програмата при завършена версия за обмен на файлове и писмени съобщения. ЛИТЕРАТУРА [1] Документацията на Speex 1.2 – www.speex.org [2] “Peer-to-Peer Communication Across Network Address Translators” Bryan Ford, Pyda Srisuresh, Dan Kegel [3] www.msdn.com – Документацията на DirectSound и WinSock 1.1 Каталог: tu-varnascience -> images -> stories -> studentska sesiq tom1 studentska sesiq tom1 -> Зависимости между питагоровите тройки и степените на простите числа studentska sesiq tom1 -> Приложение на comsol multiphysics при анализ на полета в електротехнически устройства studentska sesiq tom1 -> Blu-ray disc наследникът на dvd studentska sesiq tom1 -> Система за микроконтролерно управление на линеен оптичен сензор tsl1406R studentska sesiq tom1 -> Устройства за изследване на променливотокова верига с последователно и паралелно свързани резистор, бобина и кондензатор studentska sesiq tom1 -> Многоядрени процесори десислава Розенова Денкова нву “Васил Левски”, факултет „Артилерия, пво и кис” studentska sesiq tom1 -> Система за предаване на данни rds мария Костадинова нву „Васил Левски” studentska sesiq tom1 -> Симулационни модели за изследване и оценка на характеристиките на сървъри за данни работещи в разпределена среда Изтегляне 88.55 Kb. Сподели с приятели:
|