LINUX.ORG.RU
решено Форум — Development  

Клиентский TCP сокет, send или recv?

 , , ,


0

3

Вот есть простой tcp клиент, самый обычный socket(..), connect(..) а что дальше нужно , send или recv?

Во всех мануалах «учим сокеты» после connect идет send, т.е. мы отправляем какие-то данные серверу. Но, вот я пробую соединиться с сервером DAYTIME (13 порт), там если идет запрос send, то до запроса recv уже не доходит, сервер разрывает соединение. И как быть? Если начинать общение с сервером с recv, тогда (если сервер ожидает от нас данные) вызов recv подвесит клиента на бесконечное время.

Запутался уже совсем.

тебе нужно читать как делать таймаут на recv

и хотя у меня есть где-то свой код на это дело, но проще привести из инета

основной смысл в использовании неблокирующего сокета и функций ожидания poll или select на файловых дескрипторах.

ты встаешь в ожидании на неблокирующем сокете с неким таймаутом. из функции (poll/select) ты вернешься или если пришло событие(то есть данные в сокет) или произошла ошибка или закончился таймаут(интервал ожидания)… короче читай доки.

если все нормально - то читаешь из сокета данные, в остальных случаях - сам решаешь что делать.

тут вот обсуждается https://stackoverflow.com/questions/2876024/linux-is-there-a-read-or-recv-from-socket-with-timeout

примерно так -

struct pollfd fd;
int ret;

fd.fd = mySocket; // your socket handler 
fd.events = POLLIN;
ret = poll(&fd, 1, 1000); // 1 second for timeout
switch (ret) {
    case -1:
        // Error
        break;
    case 0:
        // Timeout 
        break;
    default:
        recv(mySocket,buf,sizeof(buf), 0); // get your data
        break;
}

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

по poll смотри ман https://man7.org/linux/man-pages/man2/poll.2.html

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)

Запутался уже совсем.

А чего тут путаться - socket(..), connect(..) устанавливают физический канал связи. Далее вступает протокол обмена. Клиент посылает запрос и ждет ответа, или молча ловит то, что шлет сервер. Все это определяет протокол обмена!

sigurd ★★★★★
()
Ответ на: комментарий от vbr

Подключаешься к серверу, с помощью send посылаешь запрос, потом с помощью recv читаешь ответ и отключаешься.

Ага - а сервер не ждет никаких запросов и на send() - обрывает канал. Или запросы идут по другому каналу.

sigurd ★★★★★
()
Последнее исправление: sigurd (всего исправлений: 1)

Если начинать общение с сервером с recv, тогда (если сервер ожидает от нас данные) вызов recv подвесит клиента на бесконечное время.

Судя по rfc сервер не ожидет данные от клиента если обмен по tcp

tyamur ★★
()

ощущается недостаток основ. очень рекомендую вот эту книгу…

UNIX: Разработка сетевых приложений (Уильям Стивенс)

сам по ней учился 20 лет назад.

в гугле полно ресурсов, где ее можно скачать бесплатно

upd: тут выше в комментариях эту книгу уже порекомендовали :)

ergo ★★★
()
Последнее исправление: ergo (всего исправлений: 1)
Development