Voice over TOR
Предлагаю для тестирования кипто VOIP-утилиту для работы через TOR (в режимах TOR -> доменное имя и TOR->скрытый сервис). Переделал с старого PGPFone: заменил транспорт на TCP и добавил адаптивный буфер для компенсации высокого jitter в TOR-туннеле. Также добавил обмен сообщениями и файлами.
Win98-XP-7-8. Полностью портируема. Работает peer-to-peer (звонить на доменное имя или TOR-hidden service). Использует DH4096+3DES.
Приветствуются замечания и пожелания.
Сайт проекта http://torfone.org (англ./рус.), там же доступны исходники (Visual C 6).
У меня -C14 тоже отказывается падать. -C16 легко роняется, если поперебирать разные значения -Q. backtrace, coredump.
комментариев: 393 документов: 4 редакций: 0
C -C14 разобрался: падает сборка с оптимизацией -o3. Это не столь важно сейчас, т.к. ILBC не особо настолько ресурсоемкий, -o2 вполне работает даже на Celeron 700MHz. По поводу -C16: именно, падает при переборе. В случае постоянного использования кодек устойчив, т.е. скорее всего проблема в моем wrapper (codecs.c), я там немного поизвращался с оригинальной компактной упаковкой OPUS-VBR-фреймов в общий пакет. Отладку затрудняет спонтанность бага. Стараюсь разобраться.
С addkey --help тоже разобрался, конечно: тупо strlen(NULL). Все исправлю одним заходом.
Если можно, вкратце опишите механизм или ткните носом в доку: бегло просмотрел вики mutt, ничего не прояснил.
Решение может состоять из следующих частей:
1. C-библиотека, реализующая протокол и ваши алгоритмы
2. Демон, использующий библиотеку и прослушивающий порты
3. UI, из которого осуществляется взаимодействие пользователя с демоном через его порты/каналы/файлы. Варианты UI приводил выше – command-line, ncurses, web-based, GTK-based и т.п.
комментариев: 393 документов: 4 редакций: 0
ncurces я использовал в одной из первых сборок, потом отказался: слишком громоздкая штука. Решил, что проще самому перевести консоль в raw, асинхронно читать с клавиатуры и написать простую процедуру обработки ESC-последовательностей для управляющих клавиш. Получилась навигация по меню стрелками, управление PTT удержанием Tab и т.д.
Но интересуют варианты взаимодействия на нижнем уровне:
Через что же лучше? Порт – это понятно, и будет сделано. Неважно, будет это control port со своим протоколом, Telnet, Web (HTTP) И т.д.
Но есть много других техник взаимодействия: системные сообщения Windows, файлы в памяти Linux, перенаправить ввод-вывод и т.д. и т.п. Интересно, что используют другие, и что лучше.
Изначально вопрос стоял об использовании OnionPhone как добавки к другим клиентам. Это можно сделать двумя способами: издать его в виде so (dll) и использовать API (всего-то пару функций: отправка команды и чтение рапортов), или запускать отдельно OnionPhone в качестве демона и подключаться к нему, используя UI. Речь идет об низкоуровневых вариантах UI. Навреное, TCP-порт здесь – лучшее решение.
ПС: также пробую собирать под Androind, используя NDK и SWIG. Низкоуровневое аудио взял с этого примера (аудио – единственный платформ-специфический код). Пока все на стадии прикидок, но надежды есть.
ППС:
кодер OPUS падает при слишком большом уровне PCM на входе. Особенно заметно при манипуляциях с AGC (-Q0, -Q1). Возможно, уже пофиксили в OPUS (попробую обновить), или придется что-то придумывать самому.Пофиксил вроде, сам протупил. После более тщательного тестирования все вместе обновлю на git.
Свобода выбора UI. Например есть программа mldonkey, это просто движок работающий как демон закачки файлов. Такая реализация позволяет существовать целому множеству разных пользовательских интерфейсов. Такой подход также закладывает потенциал расширения – допускает подключение нескольких клиентов к одному демону, который в этом случае может выполнять функцию VoIP-шлюза. Возможно что для OnionPhone это излишество, решать разработчику. Просто привёл пример как это сделано в p2p-приложениях.
Не занимался разработкой, поэтому вряд-ли обладаю квалификацией для таких советов. Лучше наверное сокет, он двунаправленый и обладает параметрами для настройки. По сравнению с каналом имеет небольшой оверхед, т.к. работает в пакетном режиме, но зато более стандартный способ коммуникации. Приложение работает в основном на локалхосте, поэтому есть смысл опционально использовать unix-сокет. Это безопасней по сравнению с портом, т.к. применяются системные права доступа.
Я всё равно не понимаю, чем хуже разделяемая библиотека. gegel, пяосните, пожалуйста. Для P2P-клиента демонизация в какой-то степени оправдана (пусть компьютер сам раздаёт файлы, пока пользователь спит и не кликает в него мышкой), но OnionPhone она зачем? С моей точки зрения, демон будет лишним процессом, а необходимость сериализации и десериализации команд для него – лишней сложностью. Для поддержания соединения у нас и так есть демон Tor, достаточно к нему подключиться, и связь, можно сказать, уже есть.
Написать свою программу, слинковав её с кодом протокола напрямую, проще, и точек сбоя в этой схеме мне представляется меньше. Свободу выбора UI разделяемая библиотека тоже не ограничивает.
комментариев: 393 документов: 4 редакций: 0
Я совершенно согласен в Вами, и этот вариант рассматривается как предпочтительный, и, конечно, будет реализован. Но хочется максимально учесть возможные ситуации с использованием OnionPhone с другими приложениями.
Надо же как-то ожидать входящие звонки.
Демон – наверное, самый простой способ использования. Продумываю возможность UI в виде вебинтерфейса, использующего WebSocket. Это не совсем знакомая мне отрасль, пока консультируюсь с web-программистом. Со стороны OnionPhone придется держать отдельный порт для подключения браузера и реализовать на С протокол WebSocket. Открывая подготовленный html-файл, имеем GUI и подключаемся к указанному порту, получаем возможность двухстороннего общения с запущенным OnionPhone, кроссплатформенно.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
[off and humor]
Слать сообщение в /var/log/syslog, а умный systemd подключится к современному аналогу устройства /dev/audio и сделает всё остальное.
[/off and humor]
Нигде не утверждалось что это хуже, а наоборот. Демон и библитека могут существовать независимо.
Какие там точки сбоя? Нужен только дополнительный слушающий сокет для управления через UI и поддержка соответствующего ему протокола.
Библиотека к пользовательскому интерфейсу вообще не имеет отношения, это только API для написания движка.
Привильней сказать, демон интегрирован с UI.
Вариантов много – записывать в лог и сообщать список пропущенных вызовов при запуске UI или выдавать их историю по команде. Записывать в канал на STDIN какой-нибудь утилиты для проигрывания мелодии вызова, отправки email или sms.
Как уже отмечалось выше, для создания части UI используется стандартное API, к OnionPhone отношения не имеющее. Но в случае интеграции демона и UI в одно приложение, для создания нового UI нужно будет и демон переписывать, т.к по сути создавать приложение с нуля, имея только библиотеку OnionPhone. Если же он реализован отдельно, то такой проблемы нет. При этом ничто не мешает создать из двух частей монолитное приложение на этапе компиляции, если будет предусмотрена такая опция.
Кстати, в таком случае проще защититься – поместить в chroot демон гораздо легче, чем комбайн демон+GUI, который потянет за собой кучу графических библиотек плюс пробема с общим X-сервером.
комментариев: 393 документов: 4 редакций: 0
Гость, огромное спасибо за pull-реквесты – фиксы моего английского.
Именно так я себе это и представлял, также абсолютно согласен с остальными вашими замечаниями.
Вначале я тоже смотрел в сторону Qt, и на самом деле такой подход мне ближе и понятней. Но это верно для тех, кто пишет на С. Большинство кодит максимум в веб, поэтому им проще как раз то, что нам сложнее.
Оказалось, что с WebSocket ситуация похожа на ту, с которой я столкнулся год назад, прикручивая SOCKS5 клиент к Торфону. Вначале, как и положено, я искал подходящие либы и пытался с ними разобраться, но потом прочитал rfc на протокол и с удивлением обнаружил, что SOCKS5-клиент на нижнем уровне реализуется десятью строчками С-кода. Точно так же, почитав спецификацию на WebSocket, обнаружил что реализация сервера на удивление проста. Клиент (браузер) открывает TCP-соединение и отсылает handshake-пакет с текстом (это делает простой Java-скрипт в html-файле). Сервер (OnionPhone) парсит полученный текст, ищет заданный подтекст, выделяет строку после него, дописывает к ней еще фиксированную строку, считает SHA1, результат кодит в base64 и вставляет в стандартный текст ответа, отсылает его обратно клиенту.
Это и вся процедура установки соединения, займет от силы 10 строк кода сервера.
Сам обмен текстовыми строками с браузером (строка команды на OnionPhone и текстовых сообщений от него, дублирующих stdout) еще проще: к UTF-8 строке в начале сервер добавляет два байта (фиксированный тип пакета и длина в байтах) и отсылает клиенту байт-пакет через установленное TCP-соединение в любой момент времени. Клиент (браузер) делает аналогично, но дополнительно добавляет еще 4 рандомные байта маски после длины, с которыми побайтно ксорит отправляемый текст.
Это все. Причем таким образом реализуется универсальный UI, который может быть использован и небраузерным клиентом.
Преимущества: кроссплатформенный GUI-клиент может быть легко реализован на HTML+Java-script, т.е. даже начинающим разработчиком под себя, используя только текстовые команды OnionPhone из описания.
Недостатки:
– не все браузеры (особенно на андроид – штатный только с 4.4) поддерживают стандарт;
– запущенный браузер – раздражитель для параноика.