строка — C ++ Winsock recv (), ненужный буфер

Я пишу консольное приложение в cpp, которое отправляет управляющие команды из файла через TCP на хост-компьютер и получает ответ.
Вся эта информация отображается на экране и записывается в файл, и это актуальная проблема. Выходная строка, кажется, хранит ненужную информацию по любой причине, даже если я пытаюсь установить фиксированную длину.

РЕДАКТИРОВАТЬ: очистил код и позаботился о возвращаемом значении recv (). Единственное, что я пока не понимаю, это то, что второй Строка recv в моем лог-файле заполнена мусором. Может быть, один из вас, ребята, сможет определить проблему.

        string cmd="";
char *sendstr=(char*)cmd.c_str();
fflush(stdin);
int n = 1, total = 0;
char temp[1024];
string inStr;
if(cmdin.is_open())
{
while(!cmdin.eof())
{
total=0;
cmd=fread();
send(serverPC, sendstr, (int)strlen(sendstr),0);
n=recv(serverPC,&temp[total],sizeof(temp)-total-1,0); // FIX THIS
total+=n;
temp[total]='\0';
inStr=temp;
fwrite(inStr,cmd);
}
cout << "Data successfully sent!\n";
}
else{
cerr<<"can't find 'cmd.cfg' file"<<endl;
}

На выходе я ожидаю:

<11:40:00> INIT
received: VELO=0.00km/h  DOT=FORW
----

Вот что я получаю:

<10:05:56> INIT
received: VELO=0.00km/h  DOT=FORW
----
<10:05:56> VELO=50.00
received: VELO=0.00km/h  DOT=FORW  VELO=0.00km/h  DOT=FORW  VELO=0.00km/h
DOT=FORW  VELO=0.00km/h  DOT=FORW  VELO=0.00km/h  DOT=FORW  VELO=0.00km/h  DOT=FORW
VELO=0.00km/h  DOT=FORW
----
<10:05:56> VELO=100.00
received: VELO=50.00km/h  DOT=FORW
----
<10:05:56> DOT=BACK
received: VELO=50.00km/h  DOT=FORW

0

Решение

Ключевой момент, который следует помнить при записи TCP-получателя, заключается в том, что TCP рассматривается как поток данных. Это означает, что когда вы выполняете прием от чего-то, отправляющего пакеты N байтов данных, вы можете получить:

  • N байт данных
  • меньше чем N байтов данных
  • больше чем N байтов данных

Предполагая, что нет отключения, переполнения буфера или другой ошибки, вы всегда будете получать то, что отправляет сервер, в порядке его отправки, но сообщения могут быть усечены или объединены на принимающей стороне. Это одна из причин того, что много [нужна цитата?] пользовательских протоколов TCP включают либо поле длины (чтобы вы знали, сколько данных вам нужно получить), либо какой-либо способ обозначения конца данных. Таким образом, ваш получатель может зацикливаться до тех пор, пока не получит нужное количество, оставляя остаток в буфере TCP для следующего приема.

Когда вы говорите, что видите «мусор», он не выглядит для меня как мусор, он выглядит как несколько пакетов данных, соединенных вместе в один.

3

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]