Была предпринята попытка выполнить операцию над объектом, который не является сокетом

Обновлено: 21.11.2024

Возможная причина. Реализация SAL Sockets может иметь ограничение на количество приложений, которые могут использовать ее одновременно. Эта ошибка может привести к сбою SAL_Startup, если это ограничение существует на платформе и оно достигнуто.

-5862 FFFFE91A SERR SKTENOTEMPTY

-5863 FFFFE919 SERR SKTEHOSTUNREACH

-5864 FFFFE918 SERR SKTEHOSTDOWN

Возможная причина: операция сокета обнаружила мертвый хост или сетевая активность на локальном хосте не была инициирована. На эти условия чаще всего указывает ошибка sal_sktetimedout.

-5865 FFFFE917 SERR SKTENAMETOOLONG

-5866 FFFFE916 SERR SKTELOOP

-5867 FFFFE915 SERR SKTECONNREFUSED

Возможная причина: не удалось установить соединение, так как целевая машина отклонила его. Обычно это происходит из-за попытки подключиться к службе, которая неактивна на внешнем хосте; то есть без запущенного серверного приложения.

-5868 FFFFE914 SERR SKTETIMEDOUT

Возможная причина: попытка подключения не удалась, так как подключенная сторона не ответила должным образом через некоторое время, или не удалось установить подключение, поскольку подключенный хост не ответил.

-5869 FFFFE913 SERR SKTETOOMANYREFS

-5870 FFFFE912 SERR SKTESHUTDOWN

Возможная причина. Запрос на отправку или получение данных был отклонен, так как сокет в этом направлении уже был закрыт предыдущим вызовом SAL_SktShutdown. При вызове SAL_SktShutdown запрашивается частичное закрытие сокета, что является сигналом о прекращении отправки и получения.

-5871 FFFFE911 SERR SKTENOTCONN

Возможная причина. Запрос на отправку или получение данных был запрещен, поскольку сокет не подключен и (при отправке дейтаграммного сокета с использованием SAL_SktSend) не был указан адрес. Любая другая операция также может возвращать эту ошибку, например, SAL_SktSetOption, устанавливающая SAL_So_Keepalive, если соединение было сброшено.

-5872 FFFFE910 SERR SKTEISCONN

Возможная причина. Запрос на подключение был сделан на уже подключенном сокете. Некоторые реализации также возвращают эту ошибку, если SAL_SktSend вызывается для подключенного сокета SAL_Sock_Dgram (для сокетов SAL_Sock_Stream параметр to в SAL_SktSend игнорируется), хотя другие реализации рассматривают это как допустимое событие.

-5873 FFFFE90F SERR SKTENOBUFS

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

-5874 FFFFE90E SERR SKTECONNRESET

Возможная причина: существующее соединение было принудительно закрыто удаленным хостом. Обычно это происходит, если одноранговое приложение на удаленном хосте внезапно останавливается, хост перезагружается или удаленный хост использует принудительное закрытие. Эта ошибка также может возникнуть, если соединение было разорвано из-за активности проверки активности, обнаружившей сбой во время выполнения одной или нескольких операций. Выполняемые операции завершаются с ошибкой SAL_Sktenetreset. Последующие операции завершаются с ошибкой SAL_Skteconnreset.

-5875 FFFFE90D SERR SKTECONNABORTED

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

-5876 FFFFE90C SERR SKTENETRESET

Возможная причина. Соединение было разорвано из-за того, что активность проверки активности обнаружила сбой во время выполнения операции. Эта ошибка также может возвращаться функцией SAL_SktSetOption, если предпринимается попытка установить SAL_So_Keepalive для соединения, которое уже не удалось.

-5877 FFFFE90B SERR SKTENETUNREACH

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

-5878 FFFFE90A SERR SKTENETDOWN

Возможная причина. Операция сокета обнаружила неработающую сеть. Это может указывать на серьезный сбой сетевой системы (то есть стека протоколов, используемого сокетами SAL), сетевого интерфейса или самой локальной сети.

-5879 FFFFE909 SERR SKTEADDRNOTAVAIL

Возможная причина. Запрошенный адрес недействителен в своем контексте. Обычно это происходит в результате попытки привязки к адресу, который недействителен для локальной машины. Это также может быть результатом SAL_SktConnect или SAL_SktSend, когда удаленный адрес или порт недействительны для удаленного компьютера (например, адрес или порт 0).

-5880 FFFFE908 SERR SKTEADDRINUSE

Возможная причина. Как правило, разрешено только одно использование каждого адреса сокета (протокол/IP-адрес/порт). Эта ошибка возникает, если приложение пытается связать сокет с IP-адресом/портом, который уже использовался для существующего сокета, или сокет, который не был закрыт должным образом, или сокет, который все еще находится в процессе закрытия.Для серверных приложений, которым необходимо привязать несколько сокетов к одному и тому же порту, рассмотрите возможность использования SAL_SktSetOption(SAL_So_Reuseaddr). Клиентские приложения обычно вообще не должны вызывать SAL_SktBind. SAL_SktConnect автоматически выбирает неиспользуемый порт. Когда SAL_SktBind вызывается с подстановочным адресом (включая SAL_Addr_Any), SAL_Skteaddrinuse может быть отложен до тех пор, пока конкретный адрес не будет зафиксирован. Это может произойти позже при вызове другой функции, включая SAL_SktConnect или SAL_SktListen.

-5881 FFFFE907 SERR SKTEAFNOSUPPORT

Возможная причина: использовался адрес, несовместимый с запрошенным протоколом. Все сокеты создаются со связанным семейством адресов (т. е. SAL_Af_Inet для интернет-протоколов) и общим типом протокола (т. е. SAL_Sock_Stream). Эта ошибка возвращается, если в вызове сокета явно запрошен неверный протокол или если для сокета используется адрес неправильного семейства (например, в SAL_SktSend).

-5882 FFFFE906 SERR SKTEPFNOSUPPORT

Возможная причина: семейство протоколов не настроено в системе или для него не существует реализации. Это сообщение имеет немного другое значение, чем SAL_Skteafnosupport. Однако в большинстве случаев они взаимозаменяемы, и все функции сокетов SAL, которые возвращают одно из этих сообщений, также указывают SAL_Skteafnosupport.

-5883 FFFFE905 SERR SKTEOPNOTSUPP

Возможная причина. Предпринятая операция не поддерживается для указанного типа объекта. Обычно это происходит, когда дескриптор сокета для сокета, который не может поддерживать эту операцию, пытается принять соединение с сокетом дейтаграммы.

-5884 FFFFE904 SERR SKTESOCKTNOSUPPORT

Объяснение: В этом семействе адресов не существует поддержки указанного типа сокета. Например, в вызове сокета может быть выбран необязательный тип SAL_Sock_Raw, а реализация вообще не поддерживает сокеты SAL_Sock_Raw.

-5885 FFFFE903 SERR SKTEPROTONOSUPPORT

Возможная причина. Запрошенный протокол не настроен в системе или для него не существует реализации. Например, вызов сокета запрашивает сокет SAL_Sock_Dgram, но указывает потоковый протокол.

-5886 FFFFE902 SERR СКТЕНОПРОТООПТ

Возможная причина: в параметре SAL_SktGetOption был указан неизвестный, недопустимый или неподдерживаемый параметр или уровень

или вызов SAL_SktSetOption.

-5887 FFFFE901 SERR SKTEПРОТОТИП

Возможная причина: в вызове функции сокета был указан протокол, который не поддерживает семантику запрошенного типа сокета. Например, протокол ARPA Internet UDP нельзя указать с типом сокета SAL_Sock_Stream.

-5888 FFFFE900 SERR SKTEMSGSIZE

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

-5889 FFFFE8FF SERR SKTEDESTADDRREQ

Объяснение: в операции с сокетом был пропущен обязательный адрес. Например, эта ошибка возвращается, если SAL_SktSend вызывается с удаленным адресом SAL_Addr_Any.

-5890 FFFFE8FE СЕРР СКТЕНОТСОК

Возможная причина: либо параметр дескриптора сокета не ссылался на допустимый сокет, либо для SAL_SktSelect член SAL_Fdset недействителен.

-5891 FFFFE8FD SERR SKTEУЖЕ ГОТОВ

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

-5892 FFFFE8FC СЕРР SKTEINPROGRESS

Возможная причина. Сокеты SAL допускают выполнение только одной блокирующей операции для каждой задачи или потока. Если выполняется любой другой вызов функции (независимо от того, ссылается ли он на этот или любой другой сокет), функция завершается с ошибкой SAL_Skteinprogress.

-5893 FFFFE8FB SERR SKTEWOULDBLOCK

Возможная причина. Эта ошибка возвращается из-за операций с неблокирующими сокетами, которые не могут быть завершены немедленно, например SAL_SktReceive, когда нет данных в очереди для чтения из сокета. Это не фатальная ошибка, и операцию следует повторить позже. Обычно SAL_Sktewouldblock сообщается как результат вызова соединения на неблокирующем сокете SAL_Sock_Stream, поскольку для установления соединения должно пройти некоторое время.

-5894 FFFFE8FA SERR SKTEMFILE

Объяснение: слишком много открытых сокетов. Каждая реализация может иметь максимальное количество доступных дескрипторов сокетов, либо глобально, либо для каждого процесса, либо для каждого потока.

-5895 FFFFE8F9 СЕРР SKTEINVAL

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

-5896 FFFFE8F8 SERR SKTEFAULT

Возможная причина: система обнаружила недопустимый адрес указателя при попытке использовать аргумент указателя вызова. Эта ошибка возникает, если приложение передает недопустимое значение указателя или если длина буфера слишком мала. Например, если длина аргумента, представляющего собой структуру SAL_Sockaddr, меньше размера (SAL_Sockaddr).

-5897 FFFFE8F7 SERR SKTEACCES

Объяснение: Предпринята попытка доступа к сокету способом, запрещенным его правами доступа. Примером является использование широковещательного адреса для SAL_SktSend без установки разрешения на широковещательную рассылку с помощью SAL_SktSetOption(SAL_So_Broadcast).

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

Начинает асинхронную операцию для принятия попытки входящего подключения.

Перегрузки

Начинает асинхронную операцию для принятия попытки входящего подключения.

Начинает асинхронную операцию, чтобы принять попытку входящего подключения и получить первый блок данных, отправленный клиентским приложением.

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

BeginAccept(AsyncCallback, Объект)

Начинает асинхронную операцию для принятия попытки входящего подключения.

Параметры

Объект, содержащий информацию о состоянии для этого запроса.

Возврат

IAsyncResult, ссылающийся на асинхронное создание сокета.

Исключения

Объект Socket закрыт.

Для этого метода требуется Windows NT.

Принимающий сокет не прослушивает соединения. Вы должны вызвать Bind(EndPoint) и Listen(Int32) перед вызовом BeginAccept(AsyncCallback, Object).

Принятый сокет привязан.

receiveSize меньше 0.

Примеры

В следующем примере кода предпринимается попытка получить входящее соединение асинхронно.

Примечания

Протоколы, ориентированные на подключение, могут использовать метод BeginAccept для асинхронной обработки входящих попыток подключения. Асинхронный прием соединений дает вам возможность отправлять и получать данные в отдельном потоке выполнения. Перед вызовом метода BeginAccept необходимо вызвать метод Listen для прослушивания и постановки в очередь входящих запросов на подключение.

Вы должны создать метод обратного вызова, реализующий делегат AsyncCallback, и передать его имя методу BeginAccept. Для этого, как минимум, вы должны передать прослушивающий объект Socket в BeginAccept через параметр состояния. Если вашему обратному вызову требуется дополнительная информация, вы можете создать небольшой класс для хранения сокета и другой необходимой информации. Передайте экземпляр этого класса в метод BeginAccept через параметр состояния.

Ваш метод обратного вызова должен вызывать метод EndAccept. Когда ваше приложение вызывает BeginAccept, система обычно использует отдельный поток для выполнения указанного метода обратного вызова и блокирует EndAccept до тех пор, пока не будет получено ожидающее соединение. EndAccept вернет новый объект Socket, который можно использовать для отправки и получения данных с удаленного хоста. Вы не можете использовать этот возвращенный Socket для приема каких-либо дополнительных подключений из очереди подключений. Если вы хотите, чтобы исходный поток блокировался после вызова метода BeginAccept, используйте WaitHandle.WaitOne. Вызовите метод Set для события ManualResetEvent в методе обратного вызова, если вы хотите, чтобы исходный поток продолжал выполняться.

Система также может использовать вызывающий поток для вызова метода обратного вызова. В этом случае свойство CompletedSynchronously в возвращаемом IAsyncResult будет установлено, чтобы указать, что метод BeginAccept завершен синхронно.

Дополнительную информацию о написании методов обратного вызова см. в разделе Маршалинг делегата как метода обратного вызова.

Чтобы отменить ожидающий вызов метода BeginAccept, закройте файл Socket. Когда метод Close вызывается во время выполнения асинхронной операции, вызывается обратный вызов, предоставляемый методу BeginAccept. Последующий вызов метода EndAccept вызовет исключение ObjectDisposedException, указывающее, что операция была отменена.

Вы можете использовать свойство RemoteEndPoint возвращенного сокета, чтобы определить сетевой адрес удаленного хоста и номер порта.

Если вы получили SocketException, используйте свойство SocketException.ErrorCode, чтобы получить конкретный код ошибки. Получив этот код, обратитесь к документации по кодам ошибок API Windows Sockets версии 2 для получения подробного описания ошибки.

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

См. также

Относится к

BeginAccept(Int32, AsyncCallback, Объект)

Начинает асинхронную операцию, чтобы принять попытку входящего подключения и получить первый блок данных, отправленный клиентским приложением.

Параметры

Количество байтов, принимаемых от отправителя.

Объект, содержащий информацию о состоянии для этого запроса.

Возврат

IAsyncResult, ссылающийся на асинхронное создание сокета.

Исключения

Объект Socket закрыт.

Для этого метода требуется Windows NT.

Принимающий сокет не прослушивает соединения. Вы должны вызвать Bind(EndPoint) и Listen(Int32) перед вызовом BeginAccept(AsyncCallback, Object).

Принятый сокет привязан.

receiveSize меньше 0.

Примеры

В следующем примере кода открывается сокет и принимается асинхронное соединение. В этом примере сокет принимает начальные 10 байт данных. Количество полученных байтов и данные отображаются на консоли делегатом обратного вызова. См. в разделе BeginReceive описание того, как принимаются оставшиеся данные.

Примечания

Протоколы, ориентированные на подключение, могут использовать метод BeginAccept для асинхронной обработки входящих попыток подключения. Асинхронный прием соединений позволяет отправлять и получать данные в отдельном потоке выполнения. Эта перегруженная версия позволяет указать количество байтов, принимаемых при начальной передаче, в параметре receiveSize.

Перед вызовом метода BeginAccept необходимо вызвать метод Listen для прослушивания и постановки в очередь входящих запросов на подключение.

Вы должны создать метод обратного вызова, реализующий делегат AsyncCallback, и передать его имя методу BeginAccept. Для этого, как минимум, вы должны передать прослушивающий объект Socket в BeginAccept через параметр состояния. Если вашему обратному вызову требуется дополнительная информация, вы можете создать небольшой класс для хранения сокета и другой необходимой информации. Передайте экземпляр этого класса в метод BeginAccept через параметр состояния.

Ваш метод обратного вызова должен вызывать метод EndAccept. Когда ваше приложение вызывает BeginAccept, система обычно использует отдельный поток для выполнения указанного метода обратного вызова и блокирует EndAccept до тех пор, пока не будет получено ожидающее соединение.

EndAccept возвращает новый сокет, который можно использовать для отправки и получения данных с удаленного хоста. Вы не можете использовать этот возвращенный Socket для приема каких-либо дополнительных подключений из очереди подключений. Если вы хотите, чтобы исходный поток блокировался после вызова метода BeginAccept, используйте WaitHandle.WaitOne. Вызовите метод Set для события ManualResetEvent в методе обратного вызова, если вы хотите, чтобы исходный поток продолжал выполняться.

Система также может использовать вызывающий поток для вызова метода обратного вызова. В этом случае свойство CompletedSynchronously в возвращаемом IAsyncResult будет установлено, чтобы указать, что метод BeginAccept завершен синхронно.

Дополнительную информацию о написании методов обратного вызова см. в разделе Маршалинг делегата как метода обратного вызова.

Чтобы отменить ожидающий вызов метода BeginAccept, закройте файл Socket. Когда метод Close вызывается во время выполнения асинхронной операции, вызывается обратный вызов, предоставляемый методу BeginAccept. Последующий вызов метода EndAccept вызовет исключение ObjectDisposedException, указывающее, что операция была отменена.

Вы можете использовать свойство RemoteEndPoint возвращенного объекта Socket, чтобы определить сетевой адрес и номер порта удаленного хоста.

Если вы получили SocketException, используйте свойство SocketException.ErrorCode, чтобы получить конкретный код ошибки. Получив этот код, обратитесь к документации по кодам ошибок API Windows Sockets версии 2 для получения подробного описания ошибки.

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

См. также

Относится к

BeginAccept(Socket, Int32, AsyncCallback, Object)

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

Параметры

Принятый объект Socket. Это значение может быть нулевым .

Максимальное количество байтов для получения.

Объект, содержащий информацию о состоянии для этого запроса.

Возврат

Объект IAsyncResult, который ссылается на создание асинхронного объекта Socket.

Исключения

Объект Socket закрыт.

Для этого метода требуется Windows NT.

Принимающий сокет не прослушивает соединения. Вы должны вызвать Bind(EndPoint) и Listen(Int32) перед вызовом BeginAccept(AsyncCallback, Object).

Принятый сокет привязан.

receiveSize меньше 0.

Примеры

В следующем примере кода открывается сокет и принимается асинхронное соединение. В этом примере сокет принимает начальные 10 байтов данных, а параметр acceptSocket имеет значение null , что заставляет метод BeginAccept создать принятый сокет. Количество полученных байтов и данные отображаются на консоли делегатом обратного вызова. См. в разделе BeginReceive описание того, как принимаются оставшиеся данные.

Примечания

Протоколы, ориентированные на подключение, могут использовать метод BeginAccept для асинхронной обработки входящих попыток подключения. Асинхронный прием соединений дает вам возможность отправлять и получать данные в отдельном потоке выполнения. Эта перегрузка позволяет указать принятый сокет в параметре acceptSocket. Если этот параметр имеет значение null , принятый сокет создается методом BeginAccept. Вы можете указать количество байтов, которые необходимо принять при начальной передаче, в параметре receiveSize.

Перед вызовом метода BeginAccept необходимо вызвать метод Listen для прослушивания и постановки в очередь входящих запросов на подключение.

Вы должны создать метод обратного вызова, реализующий делегат AsyncCallback, и передать его имя методу BeginAccept. Для этого, как минимум, вы должны передать прослушивающий объект Socket в BeginAccept через параметр состояния. Если вашему обратному вызову требуется дополнительная информация, вы можете создать небольшой класс для хранения сокета и другой необходимой информации. Передайте экземпляр этого класса в метод BeginAccept через параметр состояния.

Ваш метод обратного вызова должен вызывать метод EndAccept. Когда ваше приложение вызывает BeginAccept, система обычно использует отдельный поток для выполнения указанного метода обратного вызова и блокирует EndAccept до тех пор, пока не будет получено ожидающее соединение.

EndAccept возвращает новый объект Socket, который можно использовать для отправки и получения данных с удаленного хоста. Вы не можете использовать этот возвращенный Socket для приема каких-либо дополнительных подключений из очереди подключений. Если вы хотите, чтобы исходный поток блокировался после вызова метода BeginAccept, используйте WaitHandle.WaitOne. Вызовите метод Set для события ManualResetEvent в методе обратного вызова, если вы хотите, чтобы исходный поток продолжал выполняться.

Система также может использовать вызывающий поток для вызова метода обратного вызова. В этом случае свойство CompletedSynchronously в возвращаемом IAsyncResult будет установлено, чтобы указать, что метод BeginAccept завершен синхронно.

Дополнительную информацию о написании методов обратного вызова см. в разделе Маршалинг делегата как метода обратного вызова.

Чтобы отменить ожидающий вызов метода BeginAccept, закройте файл Socket. Когда метод Close вызывается во время выполнения асинхронной операции, вызывается обратный вызов, предоставляемый методу BeginAccept. Последующий вызов метода EndAccept вызовет исключение ObjectDisposedException, указывающее, что операция была отменена.

Вы можете использовать свойство RemoteEndPoint возвращенного объекта Socket, чтобы определить сетевой адрес удаленного хоста и номер порта.

Если вы получили SocketException, используйте свойство SocketException.ErrorCode, чтобы получить конкретный код ошибки. Получив этот код, обратитесь к документации по кодам ошибок API Windows Sockets версии 2 для получения подробного описания ошибки.

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

Читайте также: