Имеем:
распределенная система, множество клиентов общаются через маршрутизирующий сервер
Проблема:
В процессе передачи больших блоков данных одним из клиентов пакеты приходят на маршрутизатор частями, и также, частями, отсылаются адресатам. Уже на клиентах происходит буфферизация полученых кусков в цельный пакет, и последующая обработка пакета.
Возможна ситуация, когда между передачей частей большого пакета, у маршрутизатора возникает необходимость в рассылке некого небольшого нотификационного пакета. К примеру, это может быть уведомление о подключении нового клиента или нечто подобное. Если вклинить этот небольшой пакет между кусками бальшого пакета, это приведет к неадектватной реакции клиента, ожидающего что куски большого пакета идкт непрерывно. Придерживать маленький пакет на сервере, до тех пор пока не завершится отправка большого тоже не хочется, т.к. на за это время маленький пакет может потерять свою актуальность.
На текущий момент родилась только идея разнести каналы данных и команд по разным соединениям (a la FTP).
Может вы подскажете лучшее решение?
Здравствуйте, PVA, Вы писали:
PVA>Клиент1: [АААААААААА] PVA>Клиент2: [БББ] PVA>Маршрутизатор: [АА] [ААА] [БББ] [АА] [ААА] — Данные обрабатываются по мере поступления PVA>Получатели: [АААААБББАА] [ААА] — Затем обалдевают от такого мусора и валятся, что не есть гуд
Не понял как это у вас выходит? У вас UDP соединение?
PVA>>Клиент1: [АААААААААА]
PVA>>Клиент2: [БББ]
PVA>>Маршрутизатор: [АА] [ААА] [БББ] [АА] [ААА] — Данные обрабатываются по мере поступления
PVA>>Получатели: [АААААБББАА] [ААА] — Затем обалдевают от такого мусора и валятся, что не есть гуд
A>Не понял как это у вас выходит? У вас UDP соединение?
Схема — звезда. В центре — маршрутизатор (скорее сервер, ибо умен).
Например,
Клиент1 закачивает огромный файл получателям (их много — идет broadcast). Но в процессе этого дела Клиент2 посылает мааааленький пакетик с данными, который становится частью потока данных от Клиент1 (для получателей это все единый бинарный поток, из которого необходимо вычитать n байт). Вот и получается, что сначала вычитывается большой кусок данных инкапсулирующий маленький пакет. А затем (что и приводит к улету) хвост большого куска, размером с маленький.
Аналог в физике:
Вы переливаете из двух бочек различные жидкости в третью — происходит диффузия.
Так вот у меня в третьей бочке сидит Золушка, которой необходимо разделить жидкости, а это можно сделать только до того, как они перемешаются.
Здравствуйте, PVA, Вы писали: PVA>На текущий момент родилась только идея разнести каналы данных и команд по разным соединениям (a la FTP). PVA>Может вы подскажете лучшее решение? PVA>
Это- самый простой способ. Альтернатива — во введении идентификатора канала в заголовок каждого пакета. Иначе клиент никак не сможет отличить "вклиненный" пакет от "невклиненного". Но это почти то же самое, что и номер порта — только поддерживаться будет не стеком протоколов, а самим приложением.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
PVA>>На текущий момент родилась только идея разнести каналы данных и команд по разным соединениям (a la FTP). PVA>>Может вы подскажете лучшее решение? S>Это- самый простой способ. Альтернатива — во введении идентификатора канала в заголовок каждого пакета. Иначе клиент никак не сможет отличить "вклиненный" пакет от "невклиненного". Но это почти то же самое, что и номер порта — только поддерживаться будет не стеком протоколов, а самим приложением.
ПМСМ, это не поможет. Проблема в том, что сегментация происходит на промежуточном звене, и здесь более привлекательным выглядит предложенное выше решение сделать мост вместо маршрутизатора.
Здравствуйте, adontz, Вы писали:
PVA>>Клиент1 закачивает огромный файл получателям (их много — идет broadcast). A>Ну значит UDP. Тогда всё ясно.
пробачте, но мне чего-то не ясно. И причем тут UDP?