Страниц: [1]
  Печать  
Автор Тема: Передача данных по одному TCP соединению в два источника  (Прочитано 12211 раз)
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 470



Просмотр профиля
« : Августа 04, 2009, 08:44:45 pm »

Дано:
программа передаёт данные по протоколу tcp через фаерволл
Фаерволл представлен отдельным сервером (Linux)

Задача:
Наиболее простым способом продублировать все передаваемые данные на резервный сервер на фаерволле и обеспечить обратный обмен.

Рассматриваю варианты:
1) использование iptables и tee
2) написание своего сервера, транслирующего все поступающие данные
Записан
AG
QOR.Moderator
*****
Offline Offline

Сообщений: 872



Просмотр профиля WWW
« Ответ #1 : Августа 04, 2009, 08:52:59 pm »

А что делать с ответами резервного сервера?
Лучше написать свой (2) муксер-прокси, учитывающий ответы резервного сервера.

Стоит учитывать, что TCP не еси real-time протокол... А таймауты и провалы при пересылке данных по нему это вааааще песня. Хотя, естественно, все зависит от задачи.

ЗЫЖ Почему в "Общение"? ИМХО минимум тянет на "Языки и алгоритмы"...
« Последнее редактирование: Августа 04, 2009, 08:57:42 pm от AG » Записан

dmi
QOR.Admin
*****
Offline Offline

Сообщений: 470



Просмотр профиля
« Ответ #2 : Августа 04, 2009, 10:13:39 pm »

а кто как реализует резервирование сервисов с сетевым обменом?
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #3 : Августа 05, 2009, 12:16:00 am »

не совсем понял вопрос. обычно клиент умный и имеет список серверов предоставляющих сервис, и откатывается на резервный сервер, если связь с основным pвется или не устанавливается. как например DNS: primary dns, secondary dns etc.. Ну или руками, тот кто запускает клиента знает имя/ip резервного сервера, если основной не работает.
Если у вас клиент простой и умеет конектиться только к одному серверу, тогда скорее свою прогу писать, но вряд-ли фаревол, а типа прокси, которая принимает данные от одного клиента, но общается с разными серверами как будто это несколько клиентов, соответственно реальному клиенту отдает один ответ. Т.е. программа является сервером для реального клиента, и клиентами для нескольких серверов. Без понимания задачи трудно что-либо конкретней сказать.
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 470



Просмотр профиля
« Ответ #4 : Августа 05, 2009, 12:51:38 am »

В упрощённом виде у меня связь один клиент -> прокси -> два сервера. Клиент знает только про прокси.
На данный момент на прокси планируется диспетчер, который поддерживает клиентское и серверные подключения и ведёт очередь запросов для обоих сторон.
Мне эта архитектура очень не нравится, т.к. требует синхронизации данных на серверах.







Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #5 : Августа 05, 2009, 12:57:38 am »

А, перечитал еще раз. Ну да, +1 к ответу AG. А сложность такого прокси прямопропорциональна сложности протокола поверх ТСР. ТСР это просто труба для обмена, и редко используется в своем голом виде. Если клиент установив соединение передает какой-нить паблик кий, сервер в ответ тоже дает какое-то случайное число, они устанавливают криптосессию и т.д., то прокси прийдется поддерживать все криптоалгоритмы и держать N+1 криптосессий (N - кол-во серверов работающих в параллель). Если же клиент просто открывает ТСР сокет и начинает валить туда данные, то такой прокси написать совсем не сложно.
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #6 : Августа 05, 2009, 12:58:17 am »

синхронизации данных на серверах?
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #7 : Августа 05, 2009, 01:05:44 am »

Возможно это требование протокола верхнего уровня. Если дополнительный сервер именно резервный (для 100% ответа клиенту, или для 100% гарантии протоколирования данных от клиента), то никакой синхринизации быть не должно. В том то и прикол, что в ситуации, которую вы пытаетесь закрыть, будет неизбежная рассинхронизация, потому как один из серверов ушел в даун. А вот как потом сервера засинхронизировать, когда один из них поднялся из дауна - это другой вопрос.
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 470



Просмотр профиля
« Ответ #8 : Августа 05, 2009, 01:26:07 am »

Вот-вот.
Как надёжно синхронизировать данные между двумя серверами?
А между тремя?
Записан
AG
QOR.Moderator
*****
Offline Offline

Сообщений: 872



Просмотр профиля WWW
« Ответ #9 : Августа 05, 2009, 02:39:44 am »

Все это можно реализовать - не вопрос.
Но! Если резервирование серверов делается для поднятия надежности, до в такой схеме слабым звеном может оказаться прокси, ибо не резервирована эта тварь еси! Т.е. если прокси дохнет, то кердык всем премудрым коммуникациям.
Записан

ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #10 : Августа 05, 2009, 04:10:12 am »

Ну кирдык может настать и клиенту. А если клиент один, например, датчик телеметрии на каком-нить спутнике, то кирдык многомиллиардному начинанию. Такое уже было, и не раз. Может ведь быть, что между прокси и серверами какой-нить RF канал или ненадежный интернет, а между клиентом и прокси вполне себе железная витая пара.
Синхронизация данных может решаться различными способами, прокси (или "диспетчер"... "как вы яхту назовете, так она и поплывет") может участвовать в этой функциональности, а может и не учавствовать совсем. Единственное, что диспетчер гарантировано может сделать - указать пальцем какой сервер отвалился. И возможно, ему надо как-то дать знать, что сервер подняли, чтобы он переконетился и начал реплицировать данные туда. Решение задачи синхронизации данных очень зависит от того, что делает ваша система. Лучше, если серверов не два, а пять или семь, тогда мажоритарные алгоритмы можно применять. Если это действительно сбор информации, то может и не надо ничего синхронизировать, а написать вторую программу, которая будет читать данные из баз всех серверов, сортировать по времени и формировать единый поток без дырок потребителю данных. Возможно даже предупреждать, если вдруг окажется, что два из трех серверов лежали одновременно и результирующий поток основан только на данных от одного сервера, и, таким образом, не 100% достоверен Smiley

Записан
mike
QOR.Moderator
*****
Offline Offline

Сообщений: 1186


Welcome to Lunatic Asylum.


Просмотр профиля WWW
« Ответ #11 : Августа 05, 2009, 07:26:58 am »

Все это можно реализовать - не вопрос.
Но! Если резервирование серверов делается для поднятия надежности, до в такой схеме слабым звеном может оказаться прокси, ибо не резервирована эта тварь еси! Т.е. если прокси дохнет, то кердык всем премудрым коммуникациям.
можно не использовать прокси, а разрулить всё на клиенте использую DNSSRV, тогда остаётся только задача синхронизации серверов

зы. а протокол на multicast udp поменять нельзя?
Записан
1-asd
Участник
*
Offline Offline

Сообщений: 2


Просмотр профиля
« Ответ #12 : Марта 18, 2010, 04:49:09 am »

Встречался немного с другой задачей. Нужно было обработать  трафик между двумя машинами. Сложно! Страх как. Для дублирования трафика, если я правильно понял, на дополнительной машине я думаю достаточно воткнуть снифер, при минимальной обработке из него даже можно вытащить чистый поток данных.
Записан
Страниц: [1]
  Печать  
 
Перейти в: