Здравствуйте, stronciy77, Вы писали:

S>Скорость поступления данных довольно большая. В среднем 4 раза в секунду, приходят пакеты от 1кб до 4кб, очень редко более длинные, скажем по 8кб

Ну т.е., даже если 4 раза в секунду по 4К, это 16К в секунду, т.е., 128 килобит. Копейки, если ваши клиенты не сидят на телефонном модеме

S>Это строки ограниченные знаком '$' сейчас работает ретранслятор, который перенаправляет всем клиентам с такой же скоростью данные, но из-за медленных накапливается пул в памяти (от меня не зависящий) который сам медленно раздает всем, и если медленных ребят много, скажем 50 из 100 , то все начинают получать данные очень

Это вы в каждом письме повторяете. Я уже запомнил, спасибо.

S>медленно. Как програмно определять кто быстрый кто медленный я не знаю. И даже не догадываюсь.

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

S>Ок, буфер, это общая куча, или для каждого свой ? Если общая куча, то тогда будет обратный трафик, с номером, последнего принятого пакета, и нагрузка на выгребание всех данных пришедших за это время... Если у каждого свой, то как это сделать, в потоках ?

Зачем вам обратный трафик?

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

Можно сделать общий буфер, можно сделать по буферу для каждого клиента — при таком маленьком трафике любое решение будет работать. Я бы сделал общий кольцевой буфер с одним write pointer'ом, который сдвигается, когда в буфер добавляют данные, и по одному read pointer'у на каждого получателя. Но при этом может быть сложно вычислить, кто (а, вернее, на сколько) отстает больше всех — не сканировать же все 50-100 указателей каждый раз (RB-деревья рулят, но вы вряд ли захотите с ними возиться).

С другой стороны, по буферу на клиента при такой маленькой скорости тоже будет вполне адекватным решением.

Pzz>>И что им делать, бедолагам, если данные с пропусками? Они хоть должны знать-то, что не все получили?
S>А вот это проблема, потому что в принципе данные критичны ... Но как их доставлять медленным ребятам, я до сих пор не знаю !

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

Вполне адекватным может быть решение 1) написать в требованиях минимальную скорость канала к клиенту 2) закрывать соединение, если клиент не выполняет этого требования