Вы можете получить 50 байтов пакета с помощью вызова .recv
на правильно подключенном сокете (в маловероятном случае фрагментации TCP-пакета может потребоваться более одного вызова, поэтому проверяйте входящую длину, пока не получите ровно 50 байтов в руке; -).
После этого, понимание того, что C-код озадачивает. Назначения int
с (предположительно по 4 байта каждое) на Packet[9]
, Packet[13]
и т. Д. Создают впечатление, что целью является установка 4 байтов за раз в пределах Packet
, но это не то, что происходит: каждое назначение устанавливает ровно один байт в пакете, начиная с младшего байта int
, который является RHS назначения. Но эти байты являются байтами (int)(720000+armcontrolpacket->dof0_rot*1000)
и так далее ...
Так что, должны ли последние 44 байта пакета интерпретироваться как 11 4-байтовых целых чисел (со знаком «без знака») или 44 независимых значения? Я угадаю первое и сделаю ...:
import struct
f = '>x4bx11i'
values = struct.unpack(f, packet)
формат f
указывает: старшие, 4 байта без знака, окруженные двумя игнорируемыми «запасными» байтами, 11 4-байтовыми целыми числами со знаком. Кортеж values
заканчивается 15 значениями: четырьмя одиночными байтами (50, 1, 2, 1 в вашем примере), затем 11 целыми числами со знаком. Вы можете использовать ту же строку формата, чтобы упаковать измененную версию кортежа обратно в 50-байтовый пакет для повторной отправки.
Поскольку вы явно указываете длину в пакете, возможно, что разные пакеты имеют разные длины (хотя это несовместимо с объявлением фиксированной длины в вашем образце C), и в этом случае вам нужно быть немного более точным в получении и распаковывать его; однако такие детали зависят от информации, которую вы не предоставляете, поэтому я перестану пытаться угадать; -).