LINUX.ORG.RU

архитектура сервиса типа ICQ


0

1

Предположим стоит задача создать что-то типа ICQ с сервером и множеством клиентов которые изредка могут что-то передавать через сервер друг другу.

Вопрос:
как бы вы сделали подключение клиентов к серверу через постоянные соединения либо через соединения типа HTTP (запрос-ответ) ?

постоянные соединения:
+:
скорость обмена, нет необходимости открывать соединение когда нужно передать инфу (открытие соединения достаточно медленная операция)

чуть меньший трафик на протокол

-:
в пустую расходуются сокеты не занятые обменом, может из 1000 открытых сокетов реально что-то передавать будут 10

соединения типа HTTP (запрос-ответ):
+:
сокеты не простаивают

-:
долгое открытие соединения

чуть больший трафик на протокол



что скажете?!

★★★★

Ответ на: комментарий от vurdalak

на самом деле сервис никак не связан с ICQ и jabber - я про то что соединений много, а обмен относительно редкий

quest ★★★★
() автор топика

> в пустую расходуются сокеты не занятые обменом, может из 1000 открытых сокетов реально что-то передавать будут 10

Почему тебя это напрягает?

const86 ★★★★★
()
Ответ на: комментарий от quest

> на самом деле сервис никак не связан с ICQ и jabber - я про то что соединений много, а обмен относительно редкий

Тогда делай на асинхронных фреймворках и не парься.

anonymous
()
Ответ на: комментарий от const86

>Почему тебя это напрягает?

потому что может случится ситуация когда сервер не сможет уже принять новое соединение из за того что куча сокетов используется в пустую, кроме того у меня большие сомнения в скорости работы сервера при куче простаивающих сокетах.

как сделано в jabber? пока что-то не нашел, в том же SIP HTTP подобный протокол

quest ★★★★
() автор топика
Ответ на: комментарий от anonymous

>Тогда делай на асинхронных фреймворках и не парься.

типа node.js ? )))

quest ★★★★
() автор топика

> чуть меньший трафик на протокол

долгое открытие соединения

чуть больший трафик на протокол

Всё это незначительно, и подлежит пренебрежению.

REST XMLRPC SOAP etc и вперед.

redixin ★★★★
()
Ответ на: комментарий от redixin

>REST XMLRPC SOAP etc и вперед.

погуглим, но можно сейчас выжимку - вы за постоянные или за HTTP подобные соединения?

quest ★★★★
() автор топика
Ответ на: комментарий от quest

> вы за постоянные или за HTTP подобные соединения?

Я за то, что это не столь важно.

И да, еще может подойти какое-нибудь mq.

redixin ★★★★
()

в пустую расходуются сокеты не занятые обменом, может из 1000 открытых сокетов реально что-то передавать будут 10

ммм, ещё года четрые назад одна тачка тыщ 200 соединений держать без проблем могла после тюнинга.

Хотя, при опред. условиях можно использовать оба подхода. Idle-клиентов держать на поллинге, активных сажать на сокет.

true_admin ★★★★★
()
Ответ на: комментарий от redixin

«Использование SOAP для передачи сообщений увеличивает их объём и снижает скорость обработки. В системах, где скорость важна, чаще используется пересылка XML-документов через HTTP напрямую, где параметры запроса передаются как обычные HTTP-параметры.»

то бишь это за HTTP подобные соединения - типа соединение - передача - прием - закрытие соединения

quest ★★★★
() автор топика
Ответ на: комментарий от true_admin

>Idle-клиентов держать на поллинге, активных сажать на сокет.

не понял фразу. поллинг - poll/select - отслеживание состояния сокета?

quest ★★★★
() автор топика
Ответ на: комментарий от quest

> то бишь это за HTTP подобные соединения

Та не обязательно, я к тому что лучше взять что-то готовое, чем самому возиться с сокетами.

И да, похоже что mq будет в самый раз (rabbitmq например)

redixin ★★★★
()

Человек про архитектуру спросил, а не удовлетворить потребительские желания чьи-то собирался, поэтому высказывания об уже сделанных (jabber) или не сделанных продуктах ни к чему.

kiverattes ★☆
()

а есть еще udp - давным давно icq работала на нем

основной недостаток у тебя типа HTTP в том что сообщение невозможно доставить мгновенно + необходимость клииенту постоянно проверять свою почту

и этот метод и есть почти udp - пакетный

но у udp был плюс в том что - сервер мог послать клинету чтото сразу - адресс и порт помнил же

ae1234 ★★
()
Ответ на: комментарий от ae1234

Я тоже за UDP - он под твою схему идеально ложится.

Засунул сообщение в датаграму - послал серверу, сервер получил - отослал acknowledgment клиенту что получил.

А вообще не изобретай велосипед, а посмотри какой нибудь JMS сервер - тот же ActiveMQ например

grassmeister
()

HTTP не бери, он односторонний по природе. Пиши неблокируещий сервер и не парься. С очередьми сообщений все довольно сомнительно... Можешь попробовать, но мне кажется это как из пушки по воробьям.

dizza ★★★★★
()
Ответ на: комментарий от quest

не понял фразу. поллинг - poll/select - отслеживание состояния сокета?

Не, я имел в виду что слабо загруженные(idle) клиенты могут слать, скажем, HTTP-запросы раз в минуту чтобы сигнализировать «я жив». Но это всё равно будет создавать tcp-соединения которые потом будут висеть ещё некоторое время в TIME_WAIT итп, так что это плохой вариант. Кстати, подумай на тему udp, tcp тут лишний если ты не собрался файлы гонять. Тут и не будет висеть кучи соединений, и память ядра не будет расходоваться на буфера и задержки гораздо более предсказуемые итп. Короче, если тебе не нужен контроль перегрузки канала(congestion), и сообщения маленькие то udp даже удобнее. Да и файловый дескриптор будет всего один(открытого сокета), а не по одному на каждого клиента.

Правда, если есть stateful-фаервол то udp всё равно будут создавать в нём записи(«динамические правила»).

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

О, про udp уже сказали :).

Кстати, если речь про activeMQ то тогда рекомендую посмотреть на zeroMQ, он вроде как приемник activeMQ если не путаю. Но мне он с ходу не понравился т.к. не позволяет контроллировать судьбу сообщений(я, правда, доки не дочитал, может это и не так). А мне вот важно знать когда какое сообщение было доставлено или недоставлено. Зато у него есть интересные фишки типа передача сообщений между процессами через shmem.

true_admin ★★★★★
()

мде, чем дольше об этом думаешь тем все не понятнее и не понятнее...
текущая реализация tcp сервер с пулом тредов созданных при старте - accept передает tcp сокет треду и будит его.

200000 соединений это 200000 тредов столько боюсь просто не создать, а принемать через epoll боюсь относительно медленней... черт его знает как это все лепить...

quest ★★★★
() автор топика
Ответ на: комментарий от true_admin

>Не, я имел в виду что слабо загруженные(idle) клиенты могут слать, скажем, HTTP-запросы раз в минуту чтобы сигнализировать «я жив».

я так и понял в конце концов, сейчас так и сделано, я называю это ping/pong

quest ★★★★
() автор топика
Ответ на: комментарий от quest

>200000 соединений это 200000 тредов столько боюсь просто не создать, а принемать через epoll боюсь относительно медленней... черт его знает как это все лепить...

Конечно, столько не создашь. Такое количество соединений можно только через epoll/kqueue/нечто подобное обрабатывать.

proud_anon ★★★★★
()
Ответ на: комментарий от quest

вот один тред на один сокет - это редкостный маразм
это бесмысленно

а ничего быстрее их необработает чем nonblock и epoll

обычьно тредов столько сколько ядер процессора - и все сокеты распределены между ними - ну иль по например 10 тыщ сокетов на один тред (это если ты хороше умееш для мультитредов писать)

а попробуй сделать udp + tcp
по udp - идут сообщения типа я тут - я жив - есть типа новая почта
а когда начинает общение - то поднимаеться tcp соединение

ae1234 ★★
()
Ответ на: комментарий от redixin

Как то плохо сочетается

зависит от выбранного инструментария. Например, под питон есть gevent который иммитирует тредовое API и блокируемую работу с сокетами, хотя на самом деле это greenlets.

true_admin ★★★★★
()
Ответ на: комментарий от quest

на youtube где-то?

Да много где, погугли «сысоев тюннинг freebsd». У него несколько докладов по этой теме есть.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

> зависит от выбранного инструментария

Это я к тому что почему не взять готовое? Ведь как известно, продвинутый кодер реализует факториал следующим образом:

from math import factorial

redixin ★★★★
()

>в пустую расходуются сокеты не занятые обменом, может из 1000 открытых сокетов реально что-то передавать будут 10

Задумайся о передаче пресенсов.

yoghurt ★★★★★
()
Ответ на: комментарий от redixin

Это я к тому что почему не взять готовое?

Часто готовое не подходит и не всегда легко поддаётся доработке. Не скажу что свои велосипеды это шибко круто, но скажу что зачастую время и деньги это не экономит. Я в этом твёрдо уверен после администрирования целого комплекса на C, perl, python, html+php, postgres7.3 + сишные триггеры + slony(это уже я доставлял чтобы репликацию делать)+apache+ещё хрен знает что и всё это исключительно на freebsd4 i386(если не путаю).

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Конечно все завит от задачи, и важно взвесить все за и против.

redixin ★★★★
()
Ответ на: комментарий от redixin

Посмотри доки жавной либы Netty, не так уж все и страшно.

dizza ★★★★★
()
Ответ на: комментарий от redixin

Ведь как известно, продвинутый кодер реализует факториал следующим образом

...

Так реализует не продвинутый кодер, а просто вчерашний студент, осознавший кривость своего вчерашнего быдлокода. Дальше есть еще ступени развития. Вообще это класика: сюхари.

from math import factorial - это всего лишь Сю

Почему все так а не иначе? Как мне написать from socialnets import facebook?

dizza ★★★★★
()
Ответ на: комментарий от true_admin

Я в этом твёрдо уверен после администрирования целого комплекса на C, perl, python, html+php, postgres7.3 + сишные триггеры

Вот уж действительно велосипеды. Вообще тут все просто: уникальные вещи могут делать единицы, из рук обычных кодеров будут выходить такие вот нелепые велосипеды, уж луше пусть готовое используют и не рыпаются.

dizza ★★★★★
()
Ответ на: комментарий от dizza

Так реализует не продвинутый кодер

Как скажешь. Да здравствует советский велострой.

Как мне написать from socialnets import facebook?

pip install pinax

redixin ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.