Re[2]: Comet

[Vitaly Puzrin <vitaly@xxxxxxxxxxx>]

AT> On Mon, Jun 11, 2007 at 08:16:24PM +0400, Vitaly Puzrin wrote:
>> Может я не так выразился? О TCP-пакетах речи вообще не было. Данные
>> представляют собой stream. Над транспортом я не задумывался. Под
>> пакетами понимал целостные блоки информации. Имел в виду, что когда
>> клиент подключается к stream-у, есть возможность выдавать данные не с
>> произвольного байта, а округлять до ближайшего логического блока.

AT> О. Следовательно frontend должен уметь пилить на блоки. Я тоже об этом.

Ok. Типичный случай, бакендом является PHP-скрипт. Блоки уже напилены.
Задача - не сваливать их в кучу раньше времени, и при подключении
нового клиента отдавать, начиная с ближайшего блока.

Я поэтому и не врубился, зачем понадобился дополнительный
напиливальщик внутри мультиплексора, о котором вы говорили.

>> Логическим блоком, естественно, считал то, что выдаст бакенд при
>> отработке FCGI-скрипта. Какая разница, как данные побьются по пути,

AT> А если нету FCGI, а есть просто TCP-поток (цепочка мультиплексоров) ?

Если нету, то абстрактно - кранты. А реально -  может клиенту и не
потребуется напилка для того случая. Приведите пожалуйста пример, когда
встречается ситуация, которую вы описали (где при этом нужен
мультиплексор для постоянный соединений).

Мне кажется, что если мультиплексор будет простым как палка, без
наворотов с дополнительной нарезкой, это покроет 99% случаев. Просто
приведите какой-нибудь конкретный пример, если я не прав. У меня из
собственных задач висят только чат и NNTP, поэтому я не всегда могу
понять для чего нужна дополнительная функциональность.