TTcpClient

← →
Piter © (2004-04-23 20:11) [0]

Я уж думал разобрался, ан нет. Ни фига, итак компонент TTcpClient.

1) Почему в неблокирующем режиме события не вызываются (OnReceive)? Возникает только сразу OnError с кодом 10035
2) почему в блокирующем режиме события ВЫЗЫВАЮТСЯ?

← →
Verg © (2004-04-23 20:16) [1]

Можешь привести "тестовый" код?

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

← →
Piter © (2004-04-23 20:31) [2]

Блин, ну ладно, вот код:

procedure TForm1.Button1Click(Sender: TObject); begin TcpClient1.Open ; end;

← →
Piter © (2004-04-23 20:33) [3]

Забыл, вот еще:

procedure TForm1.TcpClient1Error(Sender: TObject; SocketError: Integer); begin Memo1.Lines.Add("Error "+inttostr(SocketError)); end;

← →
Piter © (2004-04-23 20:35) [4]

Попробую еще объяснить по пунктам:

1) настройки BlockMode = bmNonBlocking
2) После клика на Button1 происходит описанный Error
3) далее никаких событий не происходит вообще.

← →
Rouse_ © (2004-04-23 22:15) [5]

If no error occurs, connect returns zero. Otherwise, it returns SOCKET_ERROR, and a specific error code can be retrieved by calling WSAGetLastError.

On a blocking socket, the return value indicates success or failure of the connection attempt.

With a nonblocking socket, the connection attempt cannot be completed immediately. In this case, connect will return SOCKET_ERROR, and WSAGetLastError will return WSAEWOULDBLOCK. In this case, there are three possible scenarios:

1. Use the select function to determine the completion of the connection request by checking to see if the socket is writeable.

2. If the application is using WSAAsyncSelect to indicate interest in connection events, then the application will receive an FD_CONNECT notification indicating that the connect operation is complete (successfully or not).

3. If the application is using WSAEventSelect to indicate interest in connection events, then the associated event object will be signaled indicating that the connect operation is complete (successfully or not).

Until the connection attempt completes on a nonblocking socket, all subsequent calls to connect on the same socket will fail with the error code WSAEALREADY, and WSAEISCONN when the connection completes successfully. Due to ambiguities in version 1.1 of the Windows Sockets specification, error codes returned from connect while a connection is already pending may vary among implementations. As a result, it is not recommended that applications use multiple calls to connect to detect connection completion. If they do, they must be prepared to handle WSAEINVAL and WSAEWOULDBLOCK error values the same way that they handle WSAEALREADY, to assure robust execution.

Ну и вообще: люби MSDN - кладезь знаний мудрых :)

PS: Ты это уже статью начал писать?

← →
Piter © (2004-04-23 22:59) [6]

Ну тык я ж не использую WinApi, я использую TTcpClient и если честно ответа на поставленные вопросы я не увидел... (

Rouse_ (23.04.04 22:15) [5]
PS: Ты это уже статью начал писать?

еще нет

← →
Rouse_ © (2004-04-23 23:06) [7]

сори, перепутал с TClientSocket...
А с этим чудом, что в сабже, даже не пытался работать, уж очень не понравилось...

← →
Piter © (2004-04-23 23:19) [8]

чем?

← →
Piter © (2004-04-23 23:20) [9]

В смысле чем не понравилось?

← →
Piter © (2004-04-23 23:22) [10]

Я его использую в блокирующем режиме в своем клиенте для форума, все тип топ.
Но вот озаботился вышеозначенными вопросами... может, Цифровой Человек что подскажет

← →
Rouse_ © (2004-04-23 23:22) [11]

Прежде всего реализацией...
Ну да ладно, закончим флейм, жди ответов :)

← →
Rouse_ © (2004-04-23 23:26) [12]

> Я его использую в блокирующем режиме в своем клиенте для
> форума
Небольшой совет, а не проще ли воспользоваться WinInet?
Просто проверь свой клиент, будет ли он нормально работать с (к примеру) WinGate (и другими различными прокси...). Обычно народ жалуется за отсутствие именно этих фишек...

← →
Piter © (2004-04-24 00:09) [13]

Rouse_ (23.04.04 23:26) [12]
а не проще ли воспользоваться WinInet?

Не проще. Вопрос в другом - а лучше ли? У него свои заморочки.

Rouse_ (23.04.04 23:26) [12]
Просто проверь свой клиент, будет ли он нормально работать с (к примеру) WinGate (и другими различными прокси...).

хм, а почему нет? Если прокси - поддерживается Basic аутентификация, в точности как у IE...

← →
Rouse_ © (2004-04-24 01:30) [14]

> [13] Piter © (24.04.04 00:09)
Каждому, конечно, свое, но для работы с инетом я предпочитаю использовать WinInet, для других задач уже реализацию при помощи WinSock API...
Просто не вижу смысла изобретать велосипеды...
Хотя как знать...

← →
Verg © (2004-04-24 07:10) [15]

У этих компонентов нет "событий" в том понимании как у TClientSocket, например.
Их просто некому генерировать, кроме твоего, собственно потока. Здесь нет callback ф-ций.

В блокируемом режиме начатая операция, будь то connect, recv, accept, send не вернет управления до тех пор, пока не будет достигнут результат. Хоть положительный, хоть отрицательный.
Когда мы определяем сокет как неблокирующий, мы тем самым сообщяем ядру примерно следующее: "когда запрашиваемая нами операция ввода-вывод не может быть завершена без перевода потока в состояние ожидания, следует не переводить поток в это состояние, а вместо этого вернуть соотв. ошибку". Т.е. вызываешь connect (open), а она немедленно завершается с SOCKET_ERROR, но при этом WSAGetLastError = WSAEWOULDBLOCK. Это значение ошибки как раз и говорит нам "операция начата, но требует времени для завершения. Заходите позже".
Теперь о компонентах. Давай разберем исходник ф-ции open у TTCPClient
procedure TCustomIpClient.Open;
var
addr: TSockAddr;
begin
inherited Open;
if Active and not FConnected then
begin
addr := GetSocketAddr(FRemoteHost, FRemotePort);
FConnected := ErrorCheck(WinSock.connect(FSocket, addr, sizeof(addr))) = 0;
if FConnected then // Конечно же при неблокирующем режиме
// FConnected будет false, почти однозначно
DoConnect; // вот здесь будет вызвано "событие" OnConnect
// если в блокирующем режиме connect будет успешен

end;
end;

Вот и получается, что "событие" OnConnect вызываешь ты же сам (твой поток) и только в блокирующем режиме.

Verg (24.04.04 07:10) [15]

Да, действительно. Спасибо. Тольк никак не могу понять - зачем так сделано? Какой толк от неблокирующего режима? Зачем нужны события? При неблокирующем режиме они не вызываются, при блокирующем они нафиг не нужны, тот же самый OnConnect - зачем он, если Open не вернет управление, пока не разрешится вопрос соединение произошло или нет

> Какой толк от неблокирующего режима?

Как какой толк?

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

Все остальные твои вопросы из [16] - это не ко мне :))

я про то, что как я узнаю что пришли данные? Проверять раз в 10 секунд? :)

> Piter © (24.04.04 12:08) [18]
> я про то, что как я узнаю что пришли данные? Проверять раз
> в 10 секунд? :)

Можно и чаще.:)

Можно и select с таймаутом.

ну просто непонятно - нафига там события реализованы вообще? Они только в заблуждение вводят, все равно не работают ...

никто не скажет? НЕ верю, что события там просто так...

> Piter

у тебя же исх.тексты перед носом - это так трудно разобраться в них ?

TTcpClient Найти похожие ветки