Народ! Кто ??? Ну кто скажет причину этого глюка/фичи ?????
Цитирую то, что я писал уже разным людям...
-----------------
Касается она одной ошибки, которую
возвращает WSAGetLastError() - код 183.
Код программы выглядит примерно так :
j=send(currentsock,buf, i, 0);
Если SOCKET_ERROR==j,
достаем код ошибки строкой
Err = WSAGetLastError();
Обычно код ошибки бывает такого типа (пример)-
"WSAECONNRESET (10054)" т.е. сам код - 10054
База - 10000, а 54 - конкретная ошибка.
Но у меня (Win2k, NT4) код ошибки возващает такой - 183. И бывает это
не часто. Редко, но метко. И коннекты потом повисают в воздухе.
Т.е. из другой области. Единственный файл, где можно встретить что-то
подходящее, это "error.h" (MVV 6.0) Там такая строка -
"#define ERROR_ALREADY_EXISTS 183"
Что-то я не совсем понимаю происходящего. Что бы это значило ?
От проблемы-то я избавился (но некорректно) - просто в цикле повторяю
send, пока ошибка не пропадет - вроде работает теперь.
---------------------------------------------------------------------------------------------------
почему бы не попробовать использовать WSASend
т.к.
- ошибка (winerror.h)
#define ERROR_ALREADY_EXISTS 183L
(MSDN:ID: Q155011)Attempt to create file that already exists.
В частности при создании разл синхронизирующих объектов и этим пользуются , напр (MSDN:ID: Q243953 )
быть может мастдаевцы используют к-либо синх обекты в своих WSASoket-ах, но как всегда с buga-ми.
[fd_write] мнбюъ лшякъ.19.09.01 17:41 Автор: KMiNT21 <http://blog.kmint21.com> Статус: Member
<<<<<<<
The WSAGetLastError function returns the last network error that occurred. When a particular Windows Sockets function indicates that an error has occurred, this function should be called to retrieve the appropriate error code. This error code can be different from the error code obtained from getsockopt SO_ERROR, which is socket-specific since WSAGetLastError is for all thread-specific sockets.
A successful function call, or a call to WSAGetLastError, does not reset the error code. To reset the error code, use the WSASetLastError function call with iError set to zero. A getsockopt SO_ERROR also resets the error code to zero.
The WSAGetLastError function should not be used to check for an error value on receipt of an asynchronous message. In this case, the error value is passed in the lParam parameter of the message, and this can differ from the value returned by WSAGetLastError.
<<<<<<<
в асинхронных операциях по-видимому её нельзя использовать
твоя send() скорее всего пытается сказать что операция ещё не завершена
только ждать этого лучше не в цикле, а поставив event и ждать его
удачи
[Net] [Win32] [WinSock] WSAGetLastError() == 183 Не, не то. Сморти сюда 19.09.01 11:59 Автор: KMiNT21 <http://blog.kmint21.com> Статус: Member
> в асинхронных операциях по-видимому её нельзя использовать Кого ?? WSAGetLastError ?? Ее однозначно можно использовать. Это даже обсуждать нечего. :) Но, я думаю, ты про SEND говорил ?
send можно использовать с неблокирующими сокетами. Все описано в хелпе по WinSock. Кстати, кто хочет почитать мой перевод статьи "Синхронные и асинхронные сокеты в Windows" - go to www.uinc.ru/articles
> твоя send() скорее всего пытается сказать что операция ещё > не завершена Ну да, только она в этом случае (WSAGetLastError) другой код возвращает.
см help.
> только ждать этого лучше не в цикле, а поставив event и > ждать его Не вижу смысла. Точнее не вижу чем это лучше. Мороки с ними больше.
Судя по всему, все-таки этот код (183) возвращается тогда, когда очередь на отправку в сокеты переполнена.......
И все-таки ??
А ?
[Net] [Win32] [WinSock] WSAGetLastError() == 183 Не, не то. Сморти сюда 19.09.01 12:57 Автор: ggg <ggg> Статус: Elderman
использовать WSAGetLastError() конечно всегда можно, только не всегда она вернёт осмысленную информацию
она никогда не должна возвращать неописанные коды ошибок - это какой то глюк microsoft
поэтому нужно просто найти способ не очень криво обойти этот глюк
если ты будешь ждать просто в цикле, то всё это время твоя прога будет занимать процессор (пусть малое, но современные процессоры за это время много могут сделать)
когда же ты ждёшь event, то поток спит и не отнимает времени процессора
а при завершении асинхронной операции поток СРАЗУ продолжает выполняться (это к тому что и Sleep() тоже нехорошо использовать)
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
