Комментарии 8
Вопрос: Почему не сделать через датаграммы, концом которых будет например двойной возврат каретки. Так мы можем делить полученные данные на команды. И не надо считать сколько данных мы передаем. Мне почему-то показался такой вариант красивее.
А вообще интрересно как будет реализована многопоточность или асинхронность. Сейчас, если я правильно понимаю, сервер может принять лишь одно подключение.
Да, всё верно, сервер может работать только с одним соединением одновременно. Если мы, например, отошлём две команды, разделённые на несколько пакетов, примерно в одно и то же время, то сервер может часть их них прочитать как одну команду, а остальное как другую. Первую «некорректную» команду он попытается исполнить, что у него не получиться, а вторую, скорее всего, принять не сможет, а если сможет, то разделит на ещё большее количество команд.
Такой вариант тоже имеет право на существование. Но обычно в «сообщении» имеется заголовок, только после передачи которого передаются сами данные. Эта информация может содержать длину сообщения, контрольную сумму и другие параметры. В плане надёжности оба варианта примерно одинаковы. Если мы прочитаем пакеты не в том порядке, то вряд ли сможем это понять (если не перепутаны первый и последний пакеты в первом и втором вариантах соответственно) и будем использовать принятые данные как корректные. Для избежания подобного можно было бы передавать не только длину сообщения, но и контрольную сумму. А если мы потеряем какой-то пакет, то не сможем возобновить передачу, но это не столь критично, так как данные очень небольшие (по крайней мере пока).
Protocol Buffers же, зачем велосипед?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Удалённое исполнение системных команд по запросу через сокеты на Python 3. Часть 2. Протокол передачи данных