2013-06-12 6 views
-2

Я реализую сервер, на котором я слушаю, как клиент подключается с помощью вызова сокета accept.Время разрыва между сокетами, т.е. Accept() и recv/send calls

После того, как принимается прием, и я получаю сокет, я жду около 10-15 секунд, прежде чем совершать первый вызов recv/send.

Отправленные вызовы клиенту завершаются ошибкой с errno = 32 i.e broken pipe.

Поскольку я не контролирую клиента, у меня есть опция сокета * SO_KEEPALIVE * в принимаемом сокете.

const int keepAlive = 1; 
acceptsock = accept(sock, (struct sockaddr*)&client_addr, &client_addr_length) 
if (setsockopt(acceptsock, SOL_SOCKET, SO_KEEPALIVE, &keepAlive, sizeof(keepAlive)) < 0) 
{ 
    print(" SO_KEEPALIVE fails"); 
} 

Не могли бы вы рассказать, что может быть неправильным здесь и как мы можем предотвратить закрытие клиентского сокета?

Примечание Одна вещь, которую я хочу добавить, что если нет разрыва во времени или менее чем за 5 секунд между принимать и отправлять/вызовы ПРИЕМ, происходит связь клиент-сервер, как ожидалось.

+0

В Linux вы можете получить errno = 32 для ошибки: ENOTCONN также, что означает сокет не подключен, и цель не указана. Посмотрите, что сделанные вами системные вызовы перед запуском send/recv не возвращают ошибки. – Aravind

+1

Вы подтвердили, что 'connect()' на самом деле преуспел, и уведомил вас, что полное соединение было доступно до того, как вы начали называть 'send()'? Сокеты обычно не закрываются после простоя, а 10-15 секунд - слишком короткое время для «SO_KEEPALIVE» для закрытия мертвого соединения, а 10-15 секунд - слишком короткое время для внешнего брандмауэра/маршрутизатора для закрытия незанятое соединение. Так происходит что-то еще. Я предполагаю, что вы просто не управляете своим клиентским сокетом правильно. –

+0

@ Aravind и Remy .. Да, connect() преуспевает, потому что accept calls, который блокирует, дает действительный accpetsock. Кроме того, данные принимаются от клиента также дважды или трижды, прежде чем я получу ошибку 32.Как я уже упоминал, я не владею клиентом, а клиент работает, если нет ожидания между вызовами accept и send/receive. – Rajat

ответ

0

connect(2) и send(2) - это два отдельных системных вызова, которые делает клиент. Первый инициирует TCP three-way handshake, второй фактически заказывает данные приложения для передачи.

На стороне сервера, хотя, вы можете начать send(2) -ную данные на подключенный сокет сразу после успешнойaccept(2) (т.е. не забудьте проверить acceptsock против -1).

+0

Думаю, вы не поняли мой вопрос. Спасибо за разъяснение. Пожалуйста, повторите это снова. Я делаю проверку для acceptsock против -1, и он терпит неудачу, поскольку сокет является допустимым. – Rajat

+0

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

0

After the accept happens and I receive the socket, i wait for around 10-15 seconds before making the first recv/send call.

Почему? Вы имеете в виду, что клиент так долго отправляет данные? или что вы просто futz вокруг на сервере в течение 10-15 с между accept() и recv(), и если да, то почему?

The send calls to the client fails with errno = 32 i.e broken pipe.

Таким образом, клиент закрыл соединение.

Since I don't control the client, i have set socket option SO_KEEPALIVE in the accepted socket.

Это не остановит клиента, закрывающего соединение.

Could anyone please tell what may be going wrong here

Клиент закрывает соединение.

and how can we prevent the client socket from closing ?

Вы не можете.

+0

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

+0

@ Rajat 'Вкратце' Я уже сказал это, по словам моего выбора: «вы не можете». Не говорите мне, что я хочу сказать. У меня очень аллергия на подобные вещи. Я уже сказал то, что хотел сказать, и мне не нужен какой-либо перефразировка. Я отмечаю, что вы не ответили ни на один из моих вопросов. – EJP