Ошибка сокета 10053 , Возникает при отключении клиента.

[Krai]

Пишу приложение на TServerSocket и TClientSocket

Когда выполняю следующий код в программе клиенте, то ошибок нигде не возникает:

 if( TcpAgentClient->Connect())
    {
     TcpAgentClient->Disconnect();
      ShowMessage("Ok");
    }
    else
    {
       ShowMessage("Connected FAILURE!!!");
    };

Тоесть и клиент и сервер правильно реагируют.
Ошибка возникает когда программа сервер подает запрос на то, чтоб клиент отключился. ТОесть она передает сообщение, типа "Заверши работу", клиент его обрабатывает и завершает работу, и вот в этот момент сервер выдает ошибку сокета Asynchronous socket error 10053
Вот код обработки сообщения:

if (Command=="SERVER_Stop_job")
   {
    if (m_tcpClient->Active)
    {
      m_tcpClient->Close();
    };
   };

При этом на сервере событие OnDisconnect не происходит и сервер подключение не закрывает. А клиент не выдает никаких ошибок и закрывает соединение.

Помогите, может советом, может кодом.

з.ы.
m_tcpClient и TcpAgentClient это ссылки на один и тот же компонент. TcpAgentClient лежит на форме, m_tcpClient член класса.

Сообщение отредактировано: Krai - 27.10.05, 09:56

[Oleg2004]

Krai
WSAECONNABORTED ECONNABORTED 10053
Так и есть, соединение прервано

[exodus]

Обрабатывай ивент сокета OnError(eeDisconnet).

[Krai]

Тоесть предлагаете написать код со следующией логикой:
На сервере:
1. Если происходит событие onDisconect, то убираем из списка клиентов, того клиента кто вызвал это событие
2. Если происходит ошибка 10053, то тоже убирать из списка.

А ведь всед за 10053, через некоторый промежуток времени происходит ошибка 10054 (Удаленый хост принудительно разоравал соединение).

Да дело то не в том, что б отловить ошибку и погасить её (ErrorCode=0), а в том, что я хочу понять почему один и тот же код вызываемый в разных местах программы, в разные промежутки времени, в одном случаие на сервере проходит корректно, а в другом случаие вызывает ексепшн.

Может дело из-за того, что у меня во второй раз метод Close() вызывается из класса который вертится в отдельном потоке?
Но я пробовавал следующее: я создал метод класса Disc(), который вызвает метод Close() сокета, и вызывал Disc() с того места где все проходит нормально, и ошибок не возникало !

В чем проблема то?

[Oleg2004]

Krai
Вариантов может быть куча.
Я не особенный спец в Дельфи, но вот тут
описана ситуация близкая к вашей.
Комбинаций может быть несколько, при который происходит выдача 53-ей ошибки
53 ошибка связана с неприходом ACK от клиента или приемом FIN от клиента или с комбинациями с ними связанными.
Причем тут комбинации? А при том, что модуль TCP- это конечный логический автомат с четко заданными состояниями, и все зависит от того, в каком состоянии был автомат, когда возникла та или иная ситуация - в результате событие вроде одно, а реакций может быть несколько - ну это так, "на пальцах"
А 54-ая - это уже посылка RST - значит клиент вдогонку еще послал и его
Механизм описан ниже:

Цитата

WSAECONNABORTED (10053) Software caused connection abort.
Berkeley description: A connection abort was caused internal to your host machine. The software caused a connection abort because there is no space on the socket's queue and the socket cannot receive further connections.
WinSock description: Partly the same as Berkeley. The error can occur when the local network system aborts a connection. This would occur if WinSock aborts an established connection after data retransmission fails (receiver never acknowledges data sent on a datastream socket).
TCP/IP scenario: A connection will timeout if the local system doesn't receive an (ACK)nowledgement for data sent. It would also timeout if a (FIN)ish TCP packet is not ACK'd (and even if the FIN is ACK'd, it will eventually timeout if a FIN is not returned).
User suggestions: There are a number of things to check, that might help to identify why the failure occurred. Basically, you want to identify where the problem occurred.
· Ping the remote host you were connected to. If it doesn't respond, it might be off-line or there may be a network problem along the way. If it does respond, then this problem might have been a transient one (so you can reconnect now), or the server application you were connected to might have terminated (so you might not be able to connect again).
· Ping a local host to verify that your local network is still functioning (if on a serial connection, see next step)
· Ping your local router address. If you're on a serial connection, your local router is the IP address of the host you initially logged onto with SLIP or PPP.
· Ping a host on the same subnet as the host you were connected to (if you know one). This will verify that the destination network is functioning.
· Try a "traceroute" to the host you were connected to. This won't reveal too much unless you know the router addresses at the remote end, but it might help to identify if the problem is somewhere along the way.

WSAECONNRESET (10054) Connection reset by peer.
Berkeley description: A connection was forcibly closed by a peer. This normally results from a loss of the connection on the remote socket due to a timeout or a reboot.
WinSock description: Same as Berkeley. On a datastream socket, the connection was reset. This reset could be generated locally by the network system when it detects a connection failure, or it might be received from the remote host (in TCP terms, the remote host sent a RST packet). This error is also possible on a datagram socket; for instance, this error could result if your application sends a UDP datagram to a host, which rejects it by responding with an ICMP Port Unreachable.
User suggestions: Some network systems have commands to report statistics. In this case, it might be possible to check the count of TCP RST packets received, or ICMP Port Unreachable packets. See other suggestions under WSAECONNABORTED.

Сообщение отредактировано: Oleg2004 - 28.10.05, 06:24

[Krai]

Поборол таки.
Вообщем дело было так:
После того, как сервер отправляет команду на отключение, он еще (за спиной) посылает три пакета, а так как я по получении команды отключиться, в клиенте сразу отключался, естесвенно сервер не мог эти три пакета доставить. Вот и байда.

Спасибо Oleg2004, навел на нужные мысли.

Сообщение отредактировано: Krai - 28.10.05, 10:34

[Krai]

10.11.2005 Разобрался окончательно!!!
Никаких три служебных сообщения он не посылает. Все проблемы были из-за того, что на сервере и клиенте у меня сообщения имели разную длину. На клиенте длиньше, чем на сервере.
Понял из-за того, что столкнулся с другой проблемой, когда подряд отправляется много сообщений клиенту, вот там и стало видно, что происходит смещение.Как привел длину сообщений к одному значению, нужда в получении "трех дополнительных" сама собой отпала. Вот так вот.