Если вы не осторожны, то, что вы предлагаете, - это дыра в безопасности. Так что будьте очень осторожны - особенно когда доверяете сетевому вводу.
Вы не указали TCP или UDP, поэтому я просто дам вам общее руководство.
Для TCP или UDP, просто выделите один буфер размером N, где N - самый большой размер сообщения, которое вы, возможно, отправили с удаленного проигрывателя или сервера. Для UDP, я бы порекомендовал хранить это менее 1500 байт. Для TCP вы можете иметь большие размеры.
Для вашего сокета, будь то UDP или TCP, сделайте его неблокирующим. Это делается для того, чтобы вы не зависали игровой цикл во время ожидания данных.
Добавить размер и crc-хэш в заголовок любого сообщения. Когда вы получаете сообщение в виде пакета UDP, если размер заголовка пакета больше, чем N (что означает, что вы уже получили усеченный пакет) или хэш не соответствует тому, что вы вычисляете для размера приема, просто отклоните пакет. Я вызываю это потому, что без дополнительных проверок целостности хакеры и мошенники будут использовать вашу структуру пакетов для победы.
Для TCP вы по сути создаете свои сообщения так, как вы их описываете. Каждое сообщение имеет заголовок, определяющий количество байтов, которые должны следовать. Но сделайте то же самое, что и для UDP, добавьте свой собственный заголовок для проверки целостности. Закройте сокет, если вы когда-либо получили сообщение об ошибке и ASSERT.
В TCP из-за сегментации TCP вы можете не получить все сообщение в одном вызове recv. То есть, если вы получили только частичное сообщение, сохраните его во временном буфере. При последующем вызове recv (в следующем игровом кадре) добавьте этот буфер. Вам придется хранить переменные для отслеживания ожидаемого конца сообщения, чтобы случайно не прочитать следующее сообщение, которое могло быть отправлено.
Удачи.