Хех

получается, на одно принятое сообщение будет отправлено x N (в зависимости от того, за сколько шагов N было принято исходное сообщение)?

Получается, будет принят поток по кусочкам, а последний кусочек потока будет в data.

Напоминаю, что такая штука как TCP ориентирована не на сообщения, а на потоки. И сами сообщеньки благополучно склеиваются в одно бесконечное (пока соединение не порвут) сообщение. Тут идёт разделение только потому, что отсутствуют блокировки (чтение прерывается на таймауте) и мы смотрим на partial.

Вот в UDP — вполне себе сообщения, с началом, телом и концом.

udp не везде подойдёт - хотя бы просто потому, что не все умеют его слать))

Если посмотреть на формат HTTP — там можно заметить такие фигулины как:
1. Разделение заголовков и тела пустой строкой. Это сделано за тем, что бы если послали длинное тело — можно было бы определить его начало.
2. Наличие в заголовках "длины тела сообщения". Это сделано для того, чтобы можно было понять, когда тело вообще закончилось, и начался следующий запрос (запросы можно объединять тупым склеиванием, но с приёмом придётся заморочиться)

Поэтому самый короткий формат сообщений на TCP —
[несколько фиксированных символов длины сообщения][тело]

"1. Разделение заголовков и тела пустой строкой. Это сделано за тем, что бы если послали длинное тело — можно было бы определить его начало."

Я бы поспорил. Что один пробел, что два - разницы для парсера не будет при прочих равных.
Это хорошо только как спецсимвол - в заголовках два переноса строки не встретятся по определению, а в тексте пользовательского запроса - могут. Значит, каждый блок пользовательского запроса просто логичнее начинать с комбинации, которая никогда не встретится в заголовках =)

"Поэтому самый короткий формат сообщений на TCP —
[несколько фиксированных символов длины сообщения][тело]" - это в идеальном мире.
В реальном клали разрабы на длину вначале строки - парси как хочешь, хоть по кофейной гуще.

Мне просто интересно сделать схему приёма-отправки, которая бы позволила выбрать протокол как опцию - хочешь, tcp, хочешь - udp.

И при этому если приём tcp задать в режиме *l, то отличий от udp для пользователя не будет.

Аналогично с отправкой - хочешь, по udp, хочешь, по tcp.

Понятно, что будут вещи, которые в принципе не будут одинаковыми для протоколов - то, что в tcp будет бесконечным бинарным потоком, по udp придётся так или иначе делать большим набором датаграмм. Но это граничные условия, где один из двух неприменим, и на нём нужно изворачиваться.

Я просто за что зацепился - если мы на каждом шаге приёма кусочка по tcp будем его считать равным сообщению (и пересылать дальше), не получится ли, что мы заспамим получателя кучей повторяющихся "кусочков"? "1", потом "12", и "123" и т.д. до полной строки "12345678"?
Логичнее ведь тогда сразу создать буфер фиксированного размера - и заполнять его или до предела или до конца входящей строки. И пересылать дальше такими "пачками".

На конечном приёмнике если печать получаемого потока включить, "кусочки"-повторы не приходят?

Я, как будет время, попробую тест провести на многих подключениях - если подтвердится, сформулирую, что не так на мой взгляд.
Пока это только подозрения)

Нет, не получится "12 123 12345".

Можно заметить в примере, что мы N раз отправляем 12345678, и количество отправок равно количеству кусочков.

receive очищает буфер partial'а при каждом вызове.

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

"самый короткий формат" — он самый короткий потому, что в принципе позволяет надёжно разделять сообщения. В противном случае, мы, кто бы мог подумать, не можем разделять сообщения, потому что их нет. Приходить будет всё что нам прислали в склеенном виде, и нам или регулярками вытаскивать волшебные сигнатуры конца сообщения (что грубо и стрёмно, и может присутстовать в теле, что ломает систему), или кодировать и разделять чем-то типа \n.

TCP — это про потоки байтов, там всё склеивается.

Тогда почему каждый раз из partial высылается вся строка?

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

Я и говорю, в идеальном мире.

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

Только потому что socket.sleep. В данных условиях, это слип на пол года.