Найти - Пользователи
Полная версия: Выбор подхода
Начало » Network » Выбор подхода
1
s0rg
Здравствуйте!

Есть странная задача - сетевой сервис на голых сокетах (основное условие), который должен слушать 2 tcp порта, на одном из этих портов будут висеть клиенты (их может быть очень много) на другой - будет коннетиться удаленная машина для обработки данных (она одна). Мой сервис должен получить
данные от клиента преобразовать их в формат для обработки и, отправлять, получив результат, отдать его клиенту от которого данные пришли.

Сейчас я думаю над следующими вариантами реализации:
1. Два отдельных процесса (или два fork'а внутри одного) один - прнимает и обрабатывает данные, второй - общается с удаленной стороной, между собой их можно связать сокетом / пайпом / …
2. Epoll / libevent - Заводим два сокета слушаем оба, один подготавливаем для приема (клиентский) второй - для отправки ну и гоняем данные туда-сюда.
3. Twisted - вроде годная штука, но с первого захода, не разобрался как такое сделать.

Все будет крутится на Debian / python 2.6.6

Возможно кто-то уже реализовывал что-то подобное и может поделится опытом.
А то у меня моск уже плавится )))
o7412369815963
> на голых сокетах (основное условие),
libevent и Twisted это “на голых сокетах”?

Каким протоколом клиенты и машина обработки будут передавать/получать данные?
Данные какого типа, большой объем?

Если протокол выбирать вам, то можно легко сделать на xmlrpc.
можно zeroMQ - он ближе к “голым сокетам”, большая производительность, но посложнее.
s0rg
Протокол - обычный текст.
Обьем небольшой в буфер сокета среднее собщение влазить будет без труда.
Насчет Twisted не уверен, но чем libevent (тот же epoll) не голые сокеты?
zeroMQ - я бы c радостью, но: он работает на udp + свой протокол контоля передачи, а значит его лучше использовать на всех стадиях (и клиенты и та машина которая эти данные будет обрабатывать) а этого сделать никак нельзя, потому что клиенты и обработчик будут работать под win, а zeroMQ при работе на win-системах использует select, который не так хорош по скорости как тот же iocp, который использует libevent. Но это мелочи по сравнению с тем, что обработчик данных еще и на Delphi а под него zeroMQ - биндингов нет )
dimabest
во завернул :)
Андрей Светлов
ZeroMQ: ни слова правды :)
s0rg
Андрей Светлов
ZeroMQ: ни слова правды :)
Да, пардон с udp - погарячился, но то что он использует select под win - ясно из исходников, я в общем не против него - а даже очень за, он бы и в саму задачу вписался лучше. Но возможности нет.

P.S. Вообще хотелось бы обсудить именно задачу а не ZeroMQ :)
Андрей Светлов
Если коротко — из-за особенностей строения zeromq разница между select и iocp невелика.
Google подсказывает, что биндинги для delphi существуют.

Я не агитирую — не хотите и не надо…
s0rg
Я - то как раз хочу, но автор обработчика данных (того что на Delphi) настолько упорот, что и слышать не желает про что-то кроме сокетов, именно по этой причине использовать что-то кроме них не представляется возможным.
Андрей Светлов
Берите что знаете — и делайте. На сравнительные графики производительности не обращайте внимания. Любое асинхронное решение подойдет.
s0rg
ok, так и сделаю )
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB