Высоконадежный копировщик сделок/сигналов (обсуждение идеологии и разработка) - страница 7

 

Ок. Тогда предлагаю за рабочую модель взять сокетное соединение.

Схема работы синхронизатора:

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

Основной плюс такой системы - это экономия трафика:
- не требуются постоянные запросы от клиента. Он их примет от сервера по их наличию
- аналогично мастер-клиент отправит данные только тогда, когда будут обнаружены их изменения

Защита на случай потери связи
- клиент раз в 5 секунд посылает "Heartbeat" пакет (например 2 байта) для проверки связи с сервером
- в случае неудачной отправки (ответа не последовало) клиент переинициализирует соединение
- аналогично поступает и сервер. Если от клиента в течении 10 секунд не было контрольного, то его сокетное соединение закрывается.


Есть ли минусы у данной связки?
- например какое максимально возможное число сокетных соединений доступно?
 
sergeev:

Защита на случай потери связи
- клиент раз в 5 секунд посылает "Heartbeat" пакет (например 2 байта) для проверки связи с сервером

Это никогда не делается если связь через транспортый протокол TCP/IP, потому что связь поддерживается автоматом на уровне сокетов, т.е. операционной системой. В случае разрыва соединений и на клиенте срабатывает исключение и в его обработчике необходимо прописать, что конкретно нужно выполнить в таком случае. Что касается сервера, дык ему до лампы, т.к. если клиент отвалился, то это уже проблемы клиента.

sergeev:


- например какое максимально возможное число сокетных соединений доступно?
Для одного хоста на одном IP адресе можно задействовать максимум 65536 портов, часть из которых уже будет занята другими интернет коннектами. Ну и один порт будет все время занят серверным сокетом для прослушки.
 
Reshetov:

В случае разрыва соединений и на клиенте срабатывает исключение и в его обработчике необходимо прописать

а вы о каком исключении говорите?
я о либе WS2_32.dll. Обычные сокеты Беркли (правда в асинхронном варианте). Там исключений не видел. Определить падение можно только попыткой отправки/приема.

Всего на одном хосте для одного IP можно задействовать максимум 65537 портов, часть из которых уже будет занята другими интернет коннектами.
дык, нужен ведь всего один порт.
а интересует сколько на этот порт можно навесить сокетных соединений ?
 
sergeev:

а вы о каком исключении говорите?
я о либе WS2_32.dll. Обычные сокеты Беркли (правда в асинхронном варианте). Там исключений не видел. Определить падение можно только попыткой отправки/приема.

дык, нужен ведь всего один порт.
а интересует сколько на этот порт можно навесить сокетных соединений ?

На один порт навешивается только одно соединение. Чтобы клиент законнектился он должен знать на какой IP и номер порта выделенного на сервере. Либо вместо IP можно указать доменное имя, сокет его разрешит в IP адрес через DNS.

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

Так осуществляется соединение по транспортному протоколу TCP/IP. Все это выполняется на уровне сокетов, т.е. программировать протокол не нужно - он стандартный и уже прошит в разлеляемую библиотеку в операционной системе.

 
может что то пригодится для разработки
Файлы:
kopir.zip  397 kb
 
Reshetov:
Когда клиент законнектится, сокет выделяет ему другой порт для постоянного соединения из пула свободных, для того чтобы поддерживать на нем связь.

Юрий, за расписанные азы спасибо, но это не к месту все. Знания даёте не те.

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

 
SEVER11:
может что то пригодится для разработки

наврядли. непрофессиональный.
 
sergeev:


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

Как говориться - это Ваши личные проблемы, как вы будете применять понятие порта. Я лишь объяснил как порты используются в протоколе TCP/IP. Еще раз только повторю, что протокол стандартный, т.е. не я его придумал.

Дальше уже сами разбирайтесь, как нибудь без меня.

Успехов!

 
sergeev

А каков порядок размера сети, сколько предполагается клиентов 1000-чи, 100-ни, 10-ки, 1-цы?

А то ведь ваш сервак действительно на трафике разориться при тысячах клиентов.

 
Urain:

А каков порядок размера сети, сколько предполагается клиентов 1000-чи, 100-ни, 10-ки, 1-цы?

А то ведь ваш сервак действительно на трафике разориться при тысячах клиентов.


в том и дело. что пытаюсь продумать всесторонне. Конечно, изначально требуется вкладывать большую масштабируемость. То есть цель - делать как для 1000-ч. И не важно, что это будут использовать потом единицы.

Поэтому и пытаюсь сейчас выбрать и определиться - или скорость и микротрафик с сокетами. Или http и немалый трафик на постоянной долбежке клиентов за новой порцией инфы.

Причина обращения: