Как правильно читать с TCP-сокета в C / C ++?

Если вы фактически создаете буфер в соответствии с предложением dirks, то:

  int readResult = read(socketFileDescriptor, buffer, BUFFER_SIZE);

может полностью заполнить буфер, возможно, перезаписывая символ завершающего нуля, от которого вы зависите при извлечении в поток строк. Вам нужно:

  int readResult = read(socketFileDescriptor, buffer, BUFFER_SIZE - 1 );

Это статья, на которую я всегда ссылаюсь при работе с сокетами.

МИР SELECT ()

Он покажет вам, как надежно использовать 'select ()', и содержит некоторые другие полезные ссылки внизу для получения дополнительной информации о сокетах.

1) Другие (особенно в срочном порядке) отметили, что для буфера должно быть выделено некоторое пространство памяти. Для небольших значений N (скажем, N < = 4096) вы также можете выделить его в стеке:

#define BUFFER_SIZE 4096
char buffer[BUFFER_SIZE]

Это избавит вас от беспокойства по поводу того, что буфер delete[] должен быть исключением быть брошенным.

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

2) Для кода возврата -1 вы не должны просто немедленно возвращаться (немедленное создание исключения еще более схематично.) Существуют определенные нормальные условия, с которыми вам нужно справиться, если ваш код должен быть чем-то большим, чем короткое домашнее задание. Например, EAGAIN может быть возвращен в errno, если в настоящее время нет данных на неблокирующем сокете. Взгляните на справочную страницу для чтения (2).

Где Вы выделяете память для Вашего buffer? Строка, где Вы вызываете bzero, вызывает неопределенное поведение, так как буфер не указывает ни на какой допустимый регион памяти.

char *buffer = new char[ BUFFER_SIZE ];
// do processing

// don't forget to release
delete[] buffer;

Несколько указателей:

необходимо обработать возвращаемое значение 0, который говорит Вам, что удаленный хост закрыл сокет.

Для неблокирования сокетов, также необходимо проверить ошибочное возвращаемое значение (-1) и удостовериться, что errno не является EINPROGRESS, который ожидается.

Вам определенно нужна лучшая обработка ошибок - Вы потенциально пропускаете буфер, на который указывает 'буфер'. Который, я заметил, Вы не выделяете нигде в этом фрагменте кода.

Кто-то еще сделал правильное замечание о том, как Ваш буфер не является завершенной струной до пустого указателя, если Ваше чтение () заполняет весь буфер. Это - действительно проблема и серьезная.

Ваш размер буфера является немного маленьким, но должен работать, пока Вы не пытаетесь считать больше чем 256 байтов, или независимо от того, что Вы выделяете для него.

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

Что-то вроде этого могло бы работать на Вас:

fd_set read_set;
struct timeval timeout;

timeout.tv_sec = 60; // Time out after a minute
timeout.tv_usec = 0;

FD_ZERO(&read_set);
FD_SET(socketFileDescriptor, &read_set);

int r=select(socketFileDescriptor+1, &read_set, NULL, NULL, &timeout);

if( r<0 ) {
    // Handle the error
}

if( r==0 ) {
    // Timeout - handle that. You could try waiting again, close the socket...
}

if( r>0 ) {
    // The socket is ready for reading - call read() on it.
}

В зависимости от объема данных Вы ожидаете получать, способ, которым Вы неоднократно сканируете все сообщение для "конца"; маркер очень неэффективен. Это лучше сделано с конечным автоматом (состояния, являющиеся 'e '->'n '->'d '->'';) так, чтобы Вы только посмотрели на каждый входящий символ однажды.

И серьезно, необходимо рассмотреть нахождение, что библиотека делает все это для Вас. Это не легкое получение его право.

Только добавить к вещам из нескольких из сообщений выше:

чтение () - по крайней мере, в моей системе - возвращает ssize_t. Это похоже на size_t, кроме подписывается. В моей системе это - длинное, не интервал. Вы могли бы получить предупреждения компилятора при использовании интервала, в зависимости от системы, компилятора, и какие предупреждения Вы включили.