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

Pzz>>Не надо при проектировании framing'а полагаться на то, что фреймы эти будут использоваться строго в режиме вопрос-ответ. Ничего особо не выигрываешь, а лишь смешиваешь два логически не связанных уровня. О чем потом и пожалеешь.
AG>Ну OK — чтобы заполнить канал передачи, помимо диалога Server-Client будем передавать фильмы.
AG>Или торрент-сеть организуем
AG>Вот не знаю — что выбрать?

Не надо заполнять посторонними данными. Но и в прямом применении может оказаться необходимо:
1. Посылать несколько запросов от клиента сразу, чтобы, пока они ползут по сети, сервер мог их отрабатывать. Обычно это называется pipelining.
2. Делать, что сервер отвечает на один запрос несколькими ответами — например, сначала "принял, исполняю", потом "прогресс 50%, полёт нормальный", потом "завершил, вот финальные результаты", с интервалом в минуты между ответами. В таком случае нужно ожидать ответов сервера в произвольные моменты и давать сообщениям теги, связывая ответы с запросами.
3. Передавать внеочередные нотификации с каждой стороны о каких-то важных изменениях или о том, на что другая подписалась.
4. Уравнять роли клиента и сервера — два равноправных участника что-то делают и могут начать новые действия в любой момент.

Если что-то из этого может происходить — потребуется или менять протокол, или заранее подготовить его к такому расширению.

Pzz>>Я даже не о пропускной способности канала сейчас говорю, а о логической целостности твоего протокола.
AG>Мой протокол — это "разговор" двух человек аппаратно-программных сущностей: сервер и клиент...
AG>Что предлагается как альтернатива диалогу — передача "пустого" space-holder-а, пока требуемого контента не насобиралось?

См. выше.