Async socket exception что значит
Перейти к содержимому

Async socket exception что значит

  • автор:

Отловить ошибку Asynchronous socket error 10061 Delphi

Как, при подключении клиента, если сервер не запущен, отловить системную ошибку и выдать сообщение о недоступности сервера? Перерыр гугл, но конструкция Try..Except не работает, как и Try..Except on E:Exception do. Или как проверить доступность сервера тогда? Код, который использовал, ниже: (событие об ошибке работает, но и системная ошибка также выдается, что логично)

unit Unit1; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ScktComp; type TForm1 = class(TForm) ClientSocket1: TClientSocket; Button1: TButton; Label1: TLabel; procedure Button1Click(Sender: TObject); procedure ClientSocket1Error(Sender: TObject; Socket: TCustomWinSocket; ErrorEvent: TErrorEvent; var ErrorCode: Integer); private < Private declarations >public < Public declarations >end; var Form1: TForm1; implementation //клик на кнопку procedure TForm1.Button1Click(Sender: TObject); begin Try ClientSocket1.Open; Except On E : Exception do Label1.Caption:='Ошибка подключения'; End; end; //при ошибке procedure TForm1.ClientSocket1Error(Sender: TObject; Socket:TCustomWinSocket; ErrorEvent: TErrorEvent;var ErrorCode: Integer); begin Label1.Caption:='Ошибка';end; end. 

Отслеживать
задан 5 дек 2015 в 12:30
247 2 2 серебряных знака 10 10 бронзовых знаков

Вы скорее всего проверяли в отладочном режиме. Если запустить программу не с Delphi — ошибка будет перехвачена и выведено ваше сообщение

6 дек 2015 в 18:06

Прошу прощения, забыл упомянуть. Нет, запускал как в отладочном (тут вы верно сказали, что перехват будет), так и без него через ехешник, ошибка перехватилась, но и возникла системная ошибка windows

Async socket exception что значит

У нас проблема тоже осталась. Отключили от ИРБИС некоторые филиалы, но результаты не радуют. Такое впечатление, что любой филиал может подвесить ИРБИС. А к тому же у нас уже законсервирована картотека статей и книг несколько лет, филиалы остались с пустыми руками. При такой нестабильной работе ИРБИС о книговыдаче не может быть и речи, а мы вплотную подошли к електронному варианту книговыдачи. Никакого продвижения в работе нет, топчемся на месте. Что делать. Хотелось бы получить результативный совет.

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: CheGevara29 (IP-адрес скрыт)
Дата: 07, October, 2011 12:49

К вопросу о том что виновата сеть:
ну вот в филиале подвис клиент, запускаю каталогизатор на компе с сервером и та же ошибка (10053), помогает онли перезапуск — в этом случае тоже виновата сеть? по моему один клиент не должен страдать от того что проблемы у другого

Хотелось бы чтоб было поправлено как можно раньше. тк с 2007ой версий не было таких проблем

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: PRM (IP-адрес скрыт)
Дата: 07, October, 2011 19:14

CheGevara29 написал(а):
——————————————————-
> К вопросу о том что виновата сеть:
> ну вот в филиале подвис клиент, запускаю
> каталогизатор на компе с сервером и та же ошибка
> (10053), помогает онли перезапуск — в этом случае
> тоже виновата сеть?
.

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: OksanaN (IP-адрес скрыт)
Дата: 22, November, 2011 16:31

Такая же проблема. Подвисает программа, выдается сообщение об ошибке. У нас Ирбис64 2010.1, D6. Сначала подвисание было раз в неделю, потом чаще, сейчас каждый день. На сервере только Ирбис и Web-ирбис. У нас уже налажена электронная книговыдача. Очень мешеает работе это подвисание, т.к. приходится перезагружать весь сервер. У нас электронная выдача была еще на Ирбис64 2009. Таких проблем не было. Да и в сентябре, когда была групповая выдача и загруженность была полная, подвисал раз в неделю, а сейчас без нагрузки каждый день. Может это все же ошибка в версии 2010, а не в настройках сетей?

И еще такой вопрос: может Apach подвешивать систему? Такой вопрос возник, т.к. после перезагрузки сервера в журнале событий выходит сообщение об ошибке. Источник Apache Service. И это сообщение по времени совпадает с подвисанием системы.

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: Alio (IP-адрес скрыт)
Дата: 22, November, 2011 17:31

Если Вы утверждаете, что на 2009 версии все работало нормально, то проведите эксперимент — верните на сервере все исполняемыe модули к версии 2009 и посмотрите, что получится
Подменить следует следующие файлы:
irbis_server.exe
irbis64.dll
server_64.exe

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: OksanaN (IP-адрес скрыт)
Дата: 25, November, 2011 15:02

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

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: Alio (IP-адрес скрыт)
Дата: 25, November, 2011 16:07
Укажите даты создания для ЭТИХ трех файлов версии 2010.1
Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: OksanaN (IP-адрес скрыт)
Дата: 25, November, 2011 16:28

У меня стоит обновление D6 для 2010.1.
irbis_server.exe — 21.06.2011
irbis64.dll — 29.08.2011
server_64.exe — 29.08.2011

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: volgen (IP-адрес скрыт)
Дата: 05, December, 2011 11:51

В системе ИРБИС64 версии 2010.1 не запускается служба Irbis64_Servis (servis_64.exe от 13.12.2005) — появляется
ошибка 1111 — и мы вынуждены запускать систему как приложение.
Другие файлы:
irbis_server.exe — 17.05.2011
irbis_64.dll — 16.05.2011
server_64.exe — 19.04.2011.
эти три .еxe файлы, указанные на форуме (см. вложение1) я не нашел в обновлении D6
для версии 2010.1.

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: Михайленко Илья (IP-адрес скрыт)
Дата: 05, December, 2011 12:12

Это происходит из-за отсутствия прав у приложения на папку ИРБИС64 и все ее подпапки.
Дело в том, что когда Вы запускаете ИРБИС как приложение, он запускается с правами текущего пользователя (под которым Вы вошли в операционную систему). Когда запускаете как сервис, ИРБИС запускается (по умолчанию) от имени учетной записи SYSTEM.
Варианта решения два: либо учетной записи SYSTEM выдать необходимые права на папку ИРБИСа, либо сервис ИРБИСа запускать от имени другой учетной записи (например, той из-под которой он запускается как приложение)

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: vguseva (IP-адрес скрыт)
Дата: 09, December, 2011 04:57

Аналогичная проблема с зависаниями. Канал проверяли неоднократно, стабилен, но скорость 256 кбит/с. В постах выше указана рекомендуемая минимальная скорость 10 Мбит/с. Могут ли зависания сервера быть связаны с низкой скоростью канала до филиалов?

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: Alio (IP-адрес скрыт)
Дата: 09, December, 2011 10:04
Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: vguseva (IP-адрес скрыт)
Дата: 12, December, 2011 05:01

Я только начинаю работать с Ирбис поэтому не все понятно.
Для настройки клиентов, необходимо указать:
#IP или доменное имя сервера (library.gpntb.ru)
ServerIP=193.233.14.9
#Порт сервера. Стандартно для WEB серверов — 80
ServerPort=80
#Переключатель в режим HTTP
WebServer=1
#Путь к WebToIrbisServer.exe, который должен указываться относительно адреса сервера
WebCgi=/cgi-bin/irbis64r_91/WebToIrbisServer.exe

Эти (свои) данные вносятся в конце секции [MAIN]?

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: vguseva (IP-адрес скрыт)
Дата: 12, December, 2011 05:22

Да, и еще вопрос, какой клиентский ini имеется ввиду? Тот который лежит непосредственно на компьютере клиента и в нем необходимо изменить
ServerIP=192.168.1.250
ServerPort=6666
WebServer=0
WebCgi=

На указанные выше?

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: PRM (IP-адрес скрыт)
Дата: 12, December, 2011 20:33

Клиентские ini — это файлы cirbis*.ini (из директории Clients).
В этих файлах следует изменить значения параметров ServerIP, ServerPort, WebServer, WebCgi в секции [Main].

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: PRM (IP-адрес скрыт)
Дата: 13, January, 2012 13:48

Михайленко Илья написал(а):
——————————————————-
> Сейчас в качестве эксперимента доделываю шлюз,
> который именно так и обрабатывает запросы прежде
> чем послать их на сервер 64-го. Заодно мониторит
> обе стороны — и сервер и клиентов. Но это совсем
> другая скорость 🙁 Для выявления проблем его
> использовать будет можно, для постоянной работы —
> нет.

Илья Иванович, скажите, пожалуйста, не готова ли тестовая версия шлюза?

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: Панев Максим (IP-адрес скрыт)
Дата: 19, January, 2012 10:25

А вот и я подоспел с тем же. Уже неделю наблюдаю, как сервер виснет на мертво и клиенты на сокет ругаются. Также летом были подключены 3 филиала. Канал более менее, но по нему большой трафик (почта, АСУ вуза, дистант и прочая ересь). Понятное дело, что канал не надежен, но еще раз повторяю: это не должно приводить к полному подвисанию сервера. Пусть медленнее, но те, кто в локалке, не должны страдать от канала филиалов.
Когда стоял вопрос о переходе филиалов на наш сервер, я даже и не подозревал о существующей опасности. Придется что-то изобретать.

Готов тестировать новый шлюз.

ЗЫ. По большому счету в процессе развития технологии наткнулись на похожие с Ирбис32 ограничения, когда слабый комп тормозил всех остальных. Только теперь слабым звеном является канал, а не сам компьютер. Можно было бы перекинуться на Ирбис128, но каталогизатор в нем пока что слабоват. А филиалы, на текущем этапе, работают только в нем.

Редактировано 4 раз. Последний раз 19.01.2012 10:31 пользователем Панев Максим.

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: PRM (IP-адрес скрыт)
Дата: 19, January, 2012 12:08

OksanaN написал(а):
——————————————————-
> Здравствуйте! У нас Ирбис 64.2010.1. Постоянно
> происходит подвисание системы. Пробую
> перестартовать сервер через АРМ
> Администратор-клиент, выдает ошибку: Asinchronous
> socket error 10051. В чем может быть причина, и
> что это за ошибка? Система подвисает каждый день,
> в разное время, приходится перезагружать весь
> сервер

Как сообщает MSDN (англ.), ошибка 10051 означает:

WSAENETUNREACH
10051
Network is unreachable.
A socket operation was attempted to an unreachable network. This usually means the local software knows no route to reach the remote host.

Перевод:

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

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

Редактировано 1 раз. Последний раз 19.01.2012 12:08 пользователем PRM.

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: PRM (IP-адрес скрыт)
Дата: 19, January, 2012 12:12

Панев Максим написал(а):
——————————————————-
> Уже неделю наблюдаю,
> как сервер виснет на мертво и клиенты на сокет
> ругаются.

Максим Васильевич, ошибка 10053?

Попробовал запустить сегодня на своём ПК доступ через WebToIrbisServer. АРМ (Каталогизатор) открывается. Но, к сожалению, скорость работы в таком режиме меньше, чем в обычном.

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: Панев Максим (IP-адрес скрыт)
Дата: 19, January, 2012 13:41

На номер-то ошибки я и не посмотрел :). Да в общем-то ноги все равно из одного горшка растут.

Клиент соединяется с сервером, работает. Потом канал перегружается и получаются потери пакетов. Клиент отваливается с этой ошибкой.
Но параллельно (. ЭТО И ТРЕБУЕТСЯ ИСПРАВЛЯТЬ . ) подвисает и TCP сервер. Он перестает отвечать на какие-либо другие запросы из сети по любым каналам связи. Все остальные клиенты со стабильным каналом связи считают, что проблема в сети, а проблема, на самом деле, в зависшем сервере. Именно подобное поведение сервера недопустимо. Это и требует исправления.

Ну и само собой пользователь должен видеть «Обнаружены проблемы в сети, попробуйте подключиться позднее». А вот «Async socket error» должен быть в логах. По крайней мере именно так, по моему скромному мнению, должен выглядеть процесс обработки ошибок.

Редактировано 1 раз. Последний раз 19.01.2012 15:15 пользователем Панев Максим.

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: OksanaN (IP-адрес скрыт)
Дата: 19, January, 2012 15:00

А кто должен исправлять данную ошибку? И как?
ТСР сервер подвисает все же иногда. Уже не часто, но раз в два дня стабильно. И причем в начале рабочего дня, когда идет первый запуск АРМ Книговыдача.

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: Панев Максим (IP-адрес скрыт)
Дата: 19, January, 2012 15:16
Это исправление мы ждем от разработчиков.
Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: PRM (IP-адрес скрыт)
Дата: 20, January, 2012 09:30

Панев Максим написал(а):
——————————————————-
>
> Ну и само собой пользователь должен видеть
> «Обнаружены проблемы в сети, попробуйте
> подключиться позднее». А вот «Async socket error»
> должен быть в логах. По крайней мере именно так,
> по моему скромному мнению, должен выглядеть
> процесс обработки ошибок.

Может быть, был бы полезным лог-файл сообщений об ошибках, которые выдавались на клиенте (об ошибках АРМ и об ошибках «Async socket error»)?

OksanaN написал(а):
——————————————————-
> А кто должен исправлять данную ошибку? И как?
> ТСР сервер подвисает все же иногда. Уже не часто,
> но раз в два дня стабильно. И причем в начале
> рабочего дня, когда идет первый запуск АРМ
> Книговыдача.

Скажите, пожалуйста, а ошибка точно «socket error 10051»?
В момент появления ошибки компьютер – сервер ИРБИС пингуется (ping)?
Трассировка маршрута (команда tracert) к компьютеру – серверу ИРБИС выполняется нормально?

(
Михайленко Илья написал(а):
——————————————————-
> Большинство проблем, связанных с зависаниями
> сервера на сегодня связаны с механизмом передачи
> данных по сети: обрезка пакетов, неожиданный
> разрыв соединения и т.д. С версии 2010.1 сетевые
> ошибки уровня протокола tcp/ip стали показываться
> пользователям. Наличие таких ошибок говорит о
> проблемах в сети, которые администраторам
> необходимо решать.
)

Re: Зависает сервер с ошибкой Asynchronous socket error 10061
Пользователь: Михайленко Илья (IP-адрес скрыт)
Дата: 20, January, 2012 11:18

В системных требованиях к ИРБИС 64 указана ЛОКАЛЬНАЯ вычислительная сеть. Сервер ИРБИС64 в силу своей архитектуры НЕ ПРЕДНАЗНАЧЕН для работы в условиях сети Интернет. Если Интернет-канал 100% устойчивый — работоспособность сервера так же будет приближаться к 100%.

Такая проблема на системах с подобной архитектурой возникает не только у ИРБИС. Проблема, приводящая к неответу сервера лежит вне пределов досягаемости кода ИРБИС. Поэтому, зачастую, даже в лог-файл записать ничего не получится, т.к. работа сервера останавливается ДО точки возврата из системной функции операционной системы. Соответственно, никаких кодов возврата ошибки ИРБИС получить просто не в состоянии.

Исправить эту ситуацию можно лишь сменив архитектуру системы, что, в общем-то, и происходит в ИРБИС-128.

Отдельно о зависаниях и «нормальных» ping. Нет смысла проверять сеть, запустив десяток-другой пинг-пакетов. Сервер 64-го ведь то же не за 10 пакетов падает и не каждые 2 минуты.
Для помощи системным администраторам, что бы дать им хоть какую-то информацию о том, что приводит к сбою на сервере, сейчас и выводятся на экран сообщения об ошибках winsock.
Еще раз напоминаю, что хоть эти сообщения и выводятся клиентами/сервером ИРБИС-64, сам ИРБИС к ним не имеет никакого отношения — это сообщения модуля операционной системы, отвечающего за сетевые коммуникации. Если появляются такие ошибки — не надо ничего «крутить» в ИРБИС — нужно искать неполадки на сетевом уровне.

Event Loop¶

The event loop is the core of every asyncio application. Event loops run asynchronous tasks and callbacks, perform network IO operations, and run subprocesses.

Application developers should typically use the high-level asyncio functions, such as asyncio.run() , and should rarely need to reference the loop object or call its methods. This section is intended mostly for authors of lower-level code, libraries, and frameworks, who need finer control over the event loop behavior.

Obtaining the Event Loop

The following low-level functions can be used to get, set, or create an event loop:

Return the running event loop in the current OS thread.

Raise a RuntimeError if there is no running event loop.

This function can only be called from a coroutine or a callback.

New in version 3.7.

asyncio. get_event_loop ( ) ¶

Get the current event loop.

When called from a coroutine or a callback (e.g. scheduled with call_soon or similar API), this function will always return the running event loop.

If there is no running event loop set, the function will return the result of the get_event_loop_policy().get_event_loop() call.

Because this function has rather complex behavior (especially when custom event loop policies are in use), using the get_running_loop() function is preferred to get_event_loop() in coroutines and callbacks.

As noted above, consider using the higher-level asyncio.run() function, instead of using these lower level functions to manually create and close an event loop.

Deprecated since version 3.12: Deprecation warning is emitted if there is no current event loop. In some future Python release this will become an error.

asyncio. set_event_loop ( loop ) ¶

Set loop as the current event loop for the current OS thread.

Create and return a new event loop object.

This documentation page contains the following sections:

  • The Event Loop Methods section is the reference documentation of the event loop APIs;
  • The Callback Handles section documents the Handle and TimerHandle instances which are returned from scheduling methods such as loop.call_soon() and loop.call_later() ;
  • The Server Objects section documents types returned from event loop methods like loop.create_server() ;
  • The Event Loop Implementations section documents the SelectorEventLoop and ProactorEventLoop classes;
  • The Examples section showcases how to work with some event loop APIs.

Event Loop Methods¶

Event loops have low-level APIs for the following:

  • Running and stopping the loop
  • Scheduling callbacks
  • Scheduling delayed callbacks
  • Creating Futures and Tasks
  • Opening network connections
  • Creating network servers
  • Transferring files
  • TLS Upgrade
  • Watching file descriptors
  • Working with socket objects directly
  • DNS
  • Working with pipes
  • Unix signals
  • Executing code in thread or process pools
  • Error Handling API
  • Enabling debug mode
  • Running Subprocesses

Running and stopping the loop¶

loop. run_until_complete ( future ) ¶

Run until the future (an instance of Future ) has completed.

If the argument is a coroutine object it is implicitly scheduled to run as a asyncio.Task .

Return the Future’s result or raise its exception.

Run the event loop until stop() is called.

If stop() is called before run_forever() is called, the loop will poll the I/O selector once with a timeout of zero, run all callbacks scheduled in response to I/O events (and those that were already scheduled), and then exit.

If stop() is called while run_forever() is running, the loop will run the current batch of callbacks and then exit. Note that new callbacks scheduled by callbacks will not run in this case; instead, they will run the next time run_forever() or run_until_complete() is called.

Stop the event loop.

Return True if the event loop is currently running.

Return True if the event loop was closed.

Close the event loop.

The loop must not be running when this function is called. Any pending callbacks will be discarded.

This method clears all queues and shuts down the executor, but does not wait for the executor to finish.

This method is idempotent and irreversible. No other methods should be called after the event loop is closed.

coroutine loop. shutdown_asyncgens ( ) ¶

Schedule all currently open asynchronous generator objects to close with an aclose() call. After calling this method, the event loop will issue a warning if a new asynchronous generator is iterated. This should be used to reliably finalize all scheduled asynchronous generators.

Note that there is no need to call this function when asyncio.run() is used.

try: loop.run_forever() finally: loop.run_until_complete(loop.shutdown_asyncgens()) loop.close() 

New in version 3.6.

coroutine loop. shutdown_default_executor ( timeout = None ) ¶

Schedule the closure of the default executor and wait for it to join all of the threads in the ThreadPoolExecutor . Once this method has been called, using the default executor with loop.run_in_executor() will raise a RuntimeError .

The timeout parameter specifies the amount of time (in float seconds) the executor will be given to finish joining. With the default, None , the executor is allowed an unlimited amount of time.

If the timeout is reached, a RuntimeWarning is emitted and the default executor is terminated without waiting for its threads to finish joining.

Do not call this method when using asyncio.run() , as the latter handles default executor shutdown automatically.

New in version 3.9.

Changed in version 3.12: Added the timeout parameter.

Scheduling callbacks¶

loop. call_soon ( callback , * args , context = None ) ¶

Schedule the callback callback to be called with args arguments at the next iteration of the event loop.

Return an instance of asyncio.Handle , which can be used later to cancel the callback.

Callbacks are called in the order in which they are registered. Each callback will be called exactly once.

The optional keyword-only context argument specifies a custom contextvars.Context for the callback to run in. Callbacks use the current context when no context is provided.

Unlike call_soon_threadsafe() , this method is not thread-safe.

loop. call_soon_threadsafe ( callback , * args , context = None ) ¶

A thread-safe variant of call_soon() . When scheduling callbacks from another thread, this function must be used, since call_soon() is not thread-safe.

Raises RuntimeError if called on a loop that’s been closed. This can happen on a secondary thread when the main application is shutting down.

See the concurrency and multithreading section of the documentation.

Changed in version 3.7: The context keyword-only parameter was added. See PEP 567 for more details.

Most asyncio scheduling functions don’t allow passing keyword arguments. To do that, use functools.partial() :

# will schedule "print("Hello", flush=True)" loop.call_soon( functools.partial(print, "Hello", flush=True)) 

Using partial objects is usually more convenient than using lambdas, as asyncio can render partial objects better in debug and error messages.

Scheduling delayed callbacks¶

Event loop provides mechanisms to schedule callback functions to be called at some point in the future. Event loop uses monotonic clocks to track time.

loop. call_later ( delay , callback , * args , context = None ) ¶

Schedule callback to be called after the given delay number of seconds (can be either an int or a float).

An instance of asyncio.TimerHandle is returned which can be used to cancel the callback.

callback will be called exactly once. If two callbacks are scheduled for exactly the same time, the order in which they are called is undefined.

The optional positional args will be passed to the callback when it is called. If you want the callback to be called with keyword arguments use functools.partial() .

An optional keyword-only context argument allows specifying a custom contextvars.Context for the callback to run in. The current context is used when no context is provided.

Changed in version 3.7: The context keyword-only parameter was added. See PEP 567 for more details.

Changed in version 3.8: In Python 3.7 and earlier with the default event loop implementation, the delay could not exceed one day. This has been fixed in Python 3.8.

loop. call_at ( when , callback , * args , context = None ) ¶

Schedule callback to be called at the given absolute timestamp when (an int or a float), using the same time reference as loop.time() .

This method’s behavior is the same as call_later() .

An instance of asyncio.TimerHandle is returned which can be used to cancel the callback.

Changed in version 3.7: The context keyword-only parameter was added. See PEP 567 for more details.

Changed in version 3.8: In Python 3.7 and earlier with the default event loop implementation, the difference between when and the current time could not exceed one day. This has been fixed in Python 3.8.

Return the current time, as a float value, according to the event loop’s internal monotonic clock.

Changed in version 3.8: In Python 3.7 and earlier timeouts (relative delay or absolute when) should not exceed one day. This has been fixed in Python 3.8.

Creating Futures and Tasks¶

loop. create_future ( ) ¶

Create an asyncio.Future object attached to the event loop.

This is the preferred way to create Futures in asyncio. This lets third-party event loops provide alternative implementations of the Future object (with better performance or instrumentation).

New in version 3.5.2.

loop. create_task ( coro , * , name = None , context = None ) ¶

Schedule the execution of coroutine coro. Return a Task object.

Third-party event loops can use their own subclass of Task for interoperability. In this case, the result type is a subclass of Task .

If the name argument is provided and not None , it is set as the name of the task using Task.set_name() .

An optional keyword-only context argument allows specifying a custom contextvars.Context for the coro to run in. The current context copy is created when no context is provided.

Changed in version 3.8: Added the name parameter.

Changed in version 3.11: Added the context parameter.

loop. set_task_factory ( factory ) ¶

Set a task factory that will be used by loop.create_task() .

If factory is None the default task factory will be set. Otherwise, factory must be a callable with the signature matching (loop, coro, context=None) , where loop is a reference to the active event loop, and coro is a coroutine object. The callable must return a asyncio.Future -compatible object.

Return a task factory or None if the default one is in use.

Opening network connections¶

coroutine loop. create_connection ( protocol_factory , host = None , port = None , * , ssl = None , family = 0 , proto = 0 , flags = 0 , sock = None , local_addr = None , server_hostname = None , ssl_handshake_timeout = None , ssl_shutdown_timeout = None , happy_eyeballs_delay = None , interleave = None , all_errors = False ) ¶

Open a streaming transport connection to a given address specified by host and port.

The socket family can be either AF_INET or AF_INET6 depending on host (or the family argument, if provided).

The socket type will be SOCK_STREAM .

protocol_factory must be a callable returning an asyncio protocol implementation.

This method will try to establish the connection in the background. When successful, it returns a (transport, protocol) pair.

The chronological synopsis of the underlying operation is as follows:

  1. The connection is established and a transport is created for it.
  2. protocol_factory is called without arguments and is expected to return a protocol instance.
  3. The protocol instance is coupled with the transport by calling its connection_made() method.
  4. A (transport, protocol) tuple is returned on success.

The created transport is an implementation-dependent bidirectional stream.

    ssl: if given and not false, a SSL/TLS transport is created (by default a plain TCP transport is created). If ssl is a ssl.SSLContext object, this context is used to create the transport; if ssl is True , a default context returned from ssl.create_default_context() is used.

Note The sock argument transfers ownership of the socket to the transport created. To close the socket, call the transport’s close() method.

Changed in version 3.5: Added support for SSL/TLS in ProactorEventLoop .

Changed in version 3.6: The socket option TCP_NODELAY is set by default for all TCP connections.

Changed in version 3.7: Added the ssl_handshake_timeout parameter.

Changed in version 3.8: Added the happy_eyeballs_delay and interleave parameters.

Happy Eyeballs Algorithm: Success with Dual-Stack Hosts. When a server’s IPv4 path and protocol are working, but the server’s IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual-stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm.

Changed in version 3.11: Added the ssl_shutdown_timeout parameter.

Changed in version 3.12: all_errors was added.

The open_connection() function is a high-level alternative API. It returns a pair of ( StreamReader , StreamWriter ) that can be used directly in async/await code.

coroutine loop. create_datagram_endpoint ( protocol_factory , local_addr = None , remote_addr = None , * , family = 0 , proto = 0 , flags = 0 , reuse_port = None , allow_broadcast = None , sock = None ) ¶

Create a datagram connection.

The socket family can be either AF_INET , AF_INET6 , or AF_UNIX , depending on host (or the family argument, if provided).

The socket type will be SOCK_DGRAM .

protocol_factory must be a callable returning a protocol implementation.

A tuple of (transport, protocol) is returned on success.

  • local_addr, if given, is a (local_host, local_port) tuple used to bind the socket locally. The local_host and local_port are looked up using getaddrinfo() .
  • remote_addr, if given, is a (remote_host, remote_port) tuple used to connect the socket to a remote address. The remote_host and remote_port are looked up using getaddrinfo() .
  • family, proto, flags are the optional address family, protocol and flags to be passed through to getaddrinfo() for host resolution. If given, these should all be integers from the corresponding socket module constants.
  • reuse_port tells the kernel to allow this endpoint to be bound to the same port as other existing endpoints are bound to, so long as they all set this flag when being created. This option is not supported on Windows and some Unixes. If the SO_REUSEPORT constant is not defined then this capability is unsupported.
  • allow_broadcast tells the kernel to allow this endpoint to send messages to the broadcast address.
  • sock can optionally be specified in order to use a preexisting, already connected, socket.socket object to be used by the transport. If specified, local_addr and remote_addr should be omitted (must be None ).

Note The sock argument transfers ownership of the socket to the transport created. To close the socket, call the transport’s close() method.

Changed in version 3.4.4: The family, proto, flags, reuse_address, reuse_port, allow_broadcast, and sock parameters were added.

Changed in version 3.8.1: The reuse_address parameter is no longer supported, as using SO_REUSEADDR poses a significant security concern for UDP. Explicitly passing reuse_address=True will raise an exception.

When multiple processes with differing UIDs assign sockets to an identical UDP socket address with SO_REUSEADDR , incoming packets can become randomly distributed among the sockets.

For supported platforms, reuse_port can be used as a replacement for similar functionality. With reuse_port, SO_REUSEPORT is used instead, which specifically prevents processes with differing UIDs from assigning sockets to the same socket address.

Changed in version 3.8: Added support for Windows.

Changed in version 3.11: The reuse_address parameter, disabled since Python 3.9.0, 3.8.1, 3.7.6 and 3.6.10, has been entirely removed.

coroutine loop. create_unix_connection ( protocol_factory , path = None , * , ssl = None , sock = None , server_hostname = None , ssl_handshake_timeout = None , ssl_shutdown_timeout = None ) ¶

Create a Unix connection.

The socket family will be AF_UNIX ; socket type will be SOCK_STREAM .

A tuple of (transport, protocol) is returned on success.

path is the name of a Unix domain socket and is required, unless a sock parameter is specified. Abstract Unix sockets, str , bytes , and Path paths are supported.

See the documentation of the loop.create_connection() method for information about arguments to this method.

Changed in version 3.7: Added the ssl_handshake_timeout parameter. The path parameter can now be a path-like object .

Changed in version 3.11: Added the ssl_shutdown_timeout parameter.

Creating network servers¶

coroutine loop. create_server ( protocol_factory , host = None , port = None , * , family = socket.AF_UNSPEC , flags = socket.AI_PASSIVE , sock = None , backlog = 100 , ssl = None , reuse_address = None , reuse_port = None , ssl_handshake_timeout = None , ssl_shutdown_timeout = None , start_serving = True ) ¶

Create a TCP server (socket type SOCK_STREAM ) listening on port of the host address.

Returns a Server object.

  • protocol_factory must be a callable returning a protocol implementation.
  • The host parameter can be set to several types which determine where the server would be listening:
    • If host is a string, the TCP server is bound to a single network interface specified by host.
    • If host is a sequence of strings, the TCP server is bound to all network interfaces specified by the sequence.
    • If host is an empty string or None , all interfaces are assumed and a list of multiple sockets will be returned (most likely one for IPv4 and another one for IPv6).

    Note The sock argument transfers ownership of the socket to the server created. To close the socket, call the server’s close() method.

    Changed in version 3.5: Added support for SSL/TLS in ProactorEventLoop .

    Changed in version 3.5.1: The host parameter can be a sequence of strings.

    Changed in version 3.6: Added ssl_handshake_timeout and start_serving parameters. The socket option TCP_NODELAY is set by default for all TCP connections.

    Changed in version 3.11: Added the ssl_shutdown_timeout parameter.

    The start_server() function is a higher-level alternative API that returns a pair of StreamReader and StreamWriter that can be used in an async/await code.

    coroutine loop. create_unix_server ( protocol_factory , path = None , * , sock = None , backlog = 100 , ssl = None , ssl_handshake_timeout = None , ssl_shutdown_timeout = None , start_serving = True ) ¶

    Similar to loop.create_server() but works with the AF_UNIX socket family.

    path is the name of a Unix domain socket, and is required, unless a sock argument is provided. Abstract Unix sockets, str , bytes , and Path paths are supported.

    See the documentation of the loop.create_server() method for information about arguments to this method.

    Changed in version 3.7: Added the ssl_handshake_timeout and start_serving parameters. The path parameter can now be a Path object.

    Changed in version 3.11: Added the ssl_shutdown_timeout parameter.

    coroutine loop. connect_accepted_socket ( protocol_factory , sock , * , ssl = None , ssl_handshake_timeout = None , ssl_shutdown_timeout = None ) ¶

    Wrap an already accepted connection into a transport/protocol pair.

    This method can be used by servers that accept connections outside of asyncio but that use asyncio to handle them.

    • protocol_factory must be a callable returning a protocol implementation.
    • sock is a preexisting socket object returned from socket.accept .

    Note The sock argument transfers ownership of the socket to the transport created. To close the socket, call the transport’s close() method.

    Returns a (transport, protocol) pair.

    New in version 3.5.3.

    Changed in version 3.7: Added the ssl_handshake_timeout parameter.

    Changed in version 3.11: Added the ssl_shutdown_timeout parameter.

    Transferring files¶

    coroutine loop. sendfile ( transport , file , offset = 0 , count = None , * , fallback = True ) ¶

    Send a file over a transport. Return the total number of bytes sent.

    The method uses high-performance os.sendfile() if available.

    file must be a regular file object opened in binary mode.

    offset tells from where to start reading the file. If specified, count is the total number of bytes to transmit as opposed to sending the file until EOF is reached. File position is always updated, even when this method raises an error, and file.tell() can be used to obtain the actual number of bytes sent.

    fallback set to True makes asyncio to manually read and send the file when the platform does not support the sendfile system call (e.g. Windows or SSL socket on Unix).

    Raise SendfileNotAvailableError if the system does not support the sendfile syscall and fallback is False .

    New in version 3.7.

    TLS Upgrade¶

    coroutine loop. start_tls ( transport , protocol , sslcontext , * , server_side = False , server_hostname = None , ssl_handshake_timeout = None , ssl_shutdown_timeout = None ) ¶

    Upgrade an existing transport-based connection to TLS.

    Create a TLS coder/decoder instance and insert it between the transport and the protocol. The coder/decoder implements both transport-facing protocol and protocol-facing transport.

    Return the created two-interface instance. After await, the protocol must stop using the original transport and communicate with the returned object only because the coder caches protocol-side data and sporadically exchanges extra TLS session packets with transport.

    In some situations (e.g. when the passed transport is already closing) this may return None .

    • transport and protocol instances that methods like create_server() and create_connection() return.
    • sslcontext: a configured instance of SSLContext .
    • server_side pass True when a server-side connection is being upgraded (like the one created by create_server() ).
    • server_hostname: sets or overrides the host name that the target server’s certificate will be matched against.
    • ssl_handshake_timeout is (for a TLS connection) the time in seconds to wait for the TLS handshake to complete before aborting the connection. 60.0 seconds if None (default).
    • ssl_shutdown_timeout is the time in seconds to wait for the SSL shutdown to complete before aborting the connection. 30.0 seconds if None (default).

    New in version 3.7.

    Changed in version 3.11: Added the ssl_shutdown_timeout parameter.

    Watching file descriptors¶

    loop. add_reader ( fd , callback , * args ) ¶

    Start monitoring the fd file descriptor for read availability and invoke callback with the specified arguments once fd is available for reading.

    loop. remove_reader ( fd ) ¶

    Stop monitoring the fd file descriptor for read availability. Returns True if fd was previously being monitored for reads.

    loop. add_writer ( fd , callback , * args ) ¶

    Start monitoring the fd file descriptor for write availability and invoke callback with the specified arguments once fd is available for writing.

    loop. remove_writer ( fd ) ¶

    Stop monitoring the fd file descriptor for write availability. Returns True if fd was previously being monitored for writes.

    See also Platform Support section for some limitations of these methods.

    Working with socket objects directly¶

    In general, protocol implementations that use transport-based APIs such as loop.create_connection() and loop.create_server() are faster than implementations that work with sockets directly. However, there are some use cases when performance is not critical, and working with socket objects directly is more convenient.

    coroutine loop. sock_recv ( sock , nbytes ) ¶

    Receive up to nbytes from sock. Asynchronous version of socket.recv() .

    Return the received data as a bytes object.

    sock must be a non-blocking socket.

    Changed in version 3.7: Even though this method was always documented as a coroutine method, releases before Python 3.7 returned a Future . Since Python 3.7 this is an async def method.

    coroutine loop. sock_recv_into ( sock , buf ) ¶

    Receive data from sock into the buf buffer. Modeled after the blocking socket.recv_into() method.

    Return the number of bytes written to the buffer.

    sock must be a non-blocking socket.

    New in version 3.7.

    coroutine loop. sock_recvfrom ( sock , bufsize ) ¶

    Receive a datagram of up to bufsize from sock. Asynchronous version of socket.recvfrom() .

    Return a tuple of (received data, remote address).

    sock must be a non-blocking socket.

    New in version 3.11.

    coroutine loop. sock_recvfrom_into ( sock , buf , nbytes = 0 ) ¶

    Receive a datagram of up to nbytes from sock into buf. Asynchronous version of socket.recvfrom_into() .

    Return a tuple of (number of bytes received, remote address).

    sock must be a non-blocking socket.

    New in version 3.11.

    coroutine loop. sock_sendall ( sock , data ) ¶

    Send data to the sock socket. Asynchronous version of socket.sendall() .

    This method continues to send to the socket until either all data in data has been sent or an error occurs. None is returned on success. On error, an exception is raised. Additionally, there is no way to determine how much data, if any, was successfully processed by the receiving end of the connection.

    sock must be a non-blocking socket.

    Changed in version 3.7: Even though the method was always documented as a coroutine method, before Python 3.7 it returned a Future . Since Python 3.7, this is an async def method.

    coroutine loop. sock_sendto ( sock , data , address ) ¶

    Send a datagram from sock to address. Asynchronous version of socket.sendto() .

    Return the number of bytes sent.

    sock must be a non-blocking socket.

    New in version 3.11.

    coroutine loop. sock_connect ( sock , address ) ¶

    Connect sock to a remote socket at address.

    Asynchronous version of socket.connect() .

    sock must be a non-blocking socket.

    Changed in version 3.5.2: address no longer needs to be resolved. sock_connect will try to check if the address is already resolved by calling socket.inet_pton() . If not, loop.getaddrinfo() will be used to resolve the address.

    coroutine loop. sock_accept ( sock ) ¶

    Accept a connection. Modeled after the blocking socket.accept() method.

    The socket must be bound to an address and listening for connections. The return value is a pair (conn, address) where conn is a new socket object usable to send and receive data on the connection, and address is the address bound to the socket on the other end of the connection.

    sock must be a non-blocking socket.

    Changed in version 3.7: Even though the method was always documented as a coroutine method, before Python 3.7 it returned a Future . Since Python 3.7, this is an async def method.

    coroutine loop. sock_sendfile ( sock , file , offset = 0 , count = None , * , fallback = True ) ¶

    Send a file using high-performance os.sendfile if possible. Return the total number of bytes sent.

    Asynchronous version of socket.sendfile() .

    file must be a regular file object open in binary mode.

    offset tells from where to start reading the file. If specified, count is the total number of bytes to transmit as opposed to sending the file until EOF is reached. File position is always updated, even when this method raises an error, and file.tell() can be used to obtain the actual number of bytes sent.

    fallback, when set to True , makes asyncio manually read and send the file when the platform does not support the sendfile syscall (e.g. Windows or SSL socket on Unix).

    Raise SendfileNotAvailableError if the system does not support sendfile syscall and fallback is False .

    sock must be a non-blocking socket.

    New in version 3.7.

    DNS¶

    coroutine loop. getaddrinfo ( host , port , * , family = 0 , type = 0 , proto = 0 , flags = 0 ) ¶

    coroutine loop. getnameinfo ( sockaddr , flags = 0 ) ¶

    Changed in version 3.7: Both getaddrinfo and getnameinfo methods were always documented to return a coroutine, but prior to Python 3.7 they were, in fact, returning asyncio.Future objects. Starting with Python 3.7 both methods are coroutines.

    Working with pipes¶

    coroutine loop. connect_read_pipe ( protocol_factory , pipe ) ¶

    Register the read end of pipe in the event loop.

    protocol_factory must be a callable returning an asyncio protocol implementation.

    Return pair (transport, protocol) , where transport supports the ReadTransport interface and protocol is an object instantiated by the protocol_factory.

    With SelectorEventLoop event loop, the pipe is set to non-blocking mode.

    coroutine loop. connect_write_pipe ( protocol_factory , pipe ) ¶

    Register the write end of pipe in the event loop.

    protocol_factory must be a callable returning an asyncio protocol implementation.

    Return pair (transport, protocol) , where transport supports WriteTransport interface and protocol is an object instantiated by the protocol_factory.

    With SelectorEventLoop event loop, the pipe is set to non-blocking mode.

    SelectorEventLoop does not support the above methods on Windows. Use ProactorEventLoop instead for Windows.

    Unix signals¶

    loop. add_signal_handler ( signum , callback , * args ) ¶

    Set callback as the handler for the signum signal.

    The callback will be invoked by loop, along with other queued callbacks and runnable coroutines of that event loop. Unlike signal handlers registered using signal.signal() , a callback registered with this function is allowed to interact with the event loop.

    Raise ValueError if the signal number is invalid or uncatchable. Raise RuntimeError if there is a problem setting up the handler.

    Like signal.signal() , this function must be invoked in the main thread.

    loop. remove_signal_handler ( sig ) ¶

    Remove the handler for the sig signal.

    Return True if the signal handler was removed, or False if no handler was set for the given signal.

    Executing code in thread or process pools¶

    awaitable loop. run_in_executor ( executor , func , * args ) ¶

    Arrange for func to be called in the specified executor.

    The executor argument should be an concurrent.futures.Executor instance. The default executor is used if executor is None .

    import asyncio import concurrent.futures def blocking_io(): # File operations (such as logging) can block the # event loop: run them in a thread pool. with open('/dev/urandom', 'rb') as f: return f.read(100) def cpu_bound(): # CPU-bound operations will block the event loop: # in general it is preferable to run them in a # process pool. return sum(i * i for i in range(10 ** 7)) async def main(): loop = asyncio.get_running_loop() ## Options: # 1. Run in the default loop's executor: result = await loop.run_in_executor( None, blocking_io) print('default thread pool', result) # 2. Run in a custom thread pool: with concurrent.futures.ThreadPoolExecutor() as pool: result = await loop.run_in_executor( pool, blocking_io) print('custom thread pool', result) # 3. Run in a custom process pool: with concurrent.futures.ProcessPoolExecutor() as pool: result = await loop.run_in_executor( pool, cpu_bound) print('custom process pool', result) if __name__ == '__main__': asyncio.run(main()) 

    Note that the entry point guard ( if __name__ == ‘__main__’ ) is required for option 3 due to the peculiarities of multiprocessing , which is used by ProcessPoolExecutor . See Safe importing of main module .

    This method returns a asyncio.Future object.

    Changed in version 3.5.3: loop.run_in_executor() no longer configures the max_workers of the thread pool executor it creates, instead leaving it up to the thread pool executor ( ThreadPoolExecutor ) to set the default.

    loop. set_default_executor ( executor ) ¶

    Set executor as the default executor used by run_in_executor() . executor must be an instance of ThreadPoolExecutor .

    Changed in version 3.11: executor must be an instance of ThreadPoolExecutor .

    Error Handling API¶

    Allows customizing how exceptions are handled in the event loop.

    loop. set_exception_handler ( handler ) ¶

    Set handler as the new event loop exception handler.

    If handler is None , the default exception handler will be set. Otherwise, handler must be a callable with the signature matching (loop, context) , where loop is a reference to the active event loop, and context is a dict object containing the details of the exception (see call_exception_handler() documentation for details about context).

    If the handler is called on behalf of a Task or Handle , it is run in the contextvars.Context of that task or callback handle.

    Changed in version 3.12: The handler may be called in the Context of the task or handle where the exception originated.

    loop. get_exception_handler ( ) ¶

    Return the current exception handler, or None if no custom exception handler was set.

    New in version 3.5.2.

    loop. default_exception_handler ( context ) ¶

    Default exception handler.

    This is called when an exception occurs and no exception handler is set. This can be called by a custom exception handler that wants to defer to the default handler behavior.

    context parameter has the same meaning as in call_exception_handler() .

    loop. call_exception_handler ( context ) ¶

    Call the current event loop exception handler.

    context is a dict object containing the following keys (new keys may be introduced in future Python versions):

    • ‘message’: Error message;
    • ‘exception’ (optional): Exception object;
    • ‘future’ (optional): asyncio.Future instance;
    • ‘task’ (optional): asyncio.Task instance;
    • ‘handle’ (optional): asyncio.Handle instance;
    • ‘protocol’ (optional): Protocol instance;
    • ‘transport’ (optional): Transport instance;
    • ‘socket’ (optional): socket.socket instance;
    • ‘asyncgen’ (optional): Asynchronous generator that caused the exception.

    This method should not be overloaded in subclassed event loops. For custom exception handling, use the set_exception_handler() method.

    Enabling debug mode¶

    loop. get_debug ( ) ¶

    Get the debug mode ( bool ) of the event loop.

    The default value is True if the environment variable PYTHONASYNCIODEBUG is set to a non-empty string, False otherwise.

    loop. set_debug ( enabled : bool ) ¶

    Set the debug mode of the event loop.

    Changed in version 3.7: The new Python Development Mode can now also be used to enable the debug mode.

    loop. slow_callback_duration ¶

    This attribute can be used to set the minimum execution duration in seconds that is considered “slow”. When debug mode is enabled, “slow” callbacks are logged.

    Default value is 100 milliseconds.

    Running Subprocesses¶

    Methods described in this subsections are low-level. In regular async/await code consider using the high-level asyncio.create_subprocess_shell() and asyncio.create_subprocess_exec() convenience functions instead.

    On Windows, the default event loop ProactorEventLoop supports subprocesses, whereas SelectorEventLoop does not. See Subprocess Support on Windows for details.

    coroutine loop. subprocess_exec ( protocol_factory , * args , stdin = subprocess.PIPE , stdout = subprocess.PIPE , stderr = subprocess.PIPE , ** kwargs ) ¶

    Create a subprocess from one or more string arguments specified by args.

    args must be a list of strings represented by:

    • str ;
    • or bytes , encoded to the filesystem encoding .

    The first string specifies the program executable, and the remaining strings specify the arguments. Together, string arguments form the argv of the program.

    This is similar to the standard library subprocess.Popen class called with shell=False and the list of strings passed as the first argument; however, where Popen takes a single argument which is list of strings, subprocess_exec takes multiple string arguments.

    The protocol_factory must be a callable returning a subclass of the asyncio.SubprocessProtocol class.

    • stdin can be any of these:
      • a file-like object
      • an existing file descriptor (a positive integer), for example those created with os.pipe()
      • the subprocess.PIPE constant (default) which will create a new pipe and connect it,
      • the value None which will make the subprocess inherit the file descriptor from this process
      • the subprocess.DEVNULL constant which indicates that the special os.devnull file will be used
      • a file-like object
      • the subprocess.PIPE constant (default) which will create a new pipe and connect it,
      • the value None which will make the subprocess inherit the file descriptor from this process
      • the subprocess.DEVNULL constant which indicates that the special os.devnull file will be used
      • a file-like object
      • the subprocess.PIPE constant (default) which will create a new pipe and connect it,
      • the value None which will make the subprocess inherit the file descriptor from this process
      • the subprocess.DEVNULL constant which indicates that the special os.devnull file will be used
      • the subprocess.STDOUT constant which will connect the standard error stream to the process’ standard output stream

      If a file-like object passed as stdin, stdout or stderr represents a pipe, then the other side of this pipe should be registered with connect_write_pipe() or connect_read_pipe() for use with the event loop.

      See the constructor of the subprocess.Popen class for documentation on other arguments.

      Returns a pair of (transport, protocol) , where transport conforms to the asyncio.SubprocessTransport base class and protocol is an object instantiated by the protocol_factory.

      coroutine loop. subprocess_shell ( protocol_factory , cmd , * , stdin = subprocess.PIPE , stdout = subprocess.PIPE , stderr = subprocess.PIPE , ** kwargs ) ¶

      Create a subprocess from cmd, which can be a str or a bytes string encoded to the filesystem encoding , using the platform’s “shell” syntax.

      This is similar to the standard library subprocess.Popen class called with shell=True .

      The protocol_factory must be a callable returning a subclass of the SubprocessProtocol class.

      See subprocess_exec() for more details about the remaining arguments.

      Returns a pair of (transport, protocol) , where transport conforms to the SubprocessTransport base class and protocol is an object instantiated by the protocol_factory.

      It is the application’s responsibility to ensure that all whitespace and special characters are quoted appropriately to avoid shell injection vulnerabilities. The shlex.quote() function can be used to properly escape whitespace and special characters in strings that are going to be used to construct shell commands.

      Callback Handles¶

      class asyncio. Handle ¶

      Return the contextvars.Context object associated with the handle.

      New in version 3.12.

      Cancel the callback. If the callback has already been canceled or executed, this method has no effect.

      Return True if the callback was cancelled.

      New in version 3.7.

      class asyncio. TimerHandle ¶

      A callback wrapper object returned by loop.call_later() , and loop.call_at() .

      This class is a subclass of Handle .

      Return a scheduled callback time as float seconds.

      The time is an absolute timestamp, using the same time reference as loop.time() .

      New in version 3.7.

      Server Objects¶

      Do not instantiate the Server class directly.

      class asyncio. Server ¶

      Server objects are asynchronous context managers. When used in an async with statement, it’s guaranteed that the Server object is closed and not accepting new connections when the async with statement is completed:

      srv = await loop.create_server(. ) async with srv: # some code # At this point, srv is closed and no longer accepts new connections. 

      Changed in version 3.7: Server object is an asynchronous context manager since Python 3.7.

      Changed in version 3.11: This class was exposed publicly as asyncio.Server in Python 3.9.11, 3.10.3 and 3.11.

      Stop serving: close listening sockets and set the sockets attribute to None .

      The sockets that represent existing incoming client connections are left open.

      The server is closed asynchronously; use the wait_closed() coroutine to wait until the server is closed (and no more connections are active).

      Return the event loop associated with the server object.

      New in version 3.7.

      coroutine start_serving ( ) ¶

      Start accepting connections.

      This method is idempotent, so it can be called when the server is already serving.

      The start_serving keyword-only parameter to loop.create_server() and asyncio.start_server() allows creating a Server object that is not accepting connections initially. In this case Server.start_serving() , or Server.serve_forever() can be used to make the Server start accepting connections.

      New in version 3.7.

      coroutine serve_forever ( ) ¶

      Start accepting connections until the coroutine is cancelled. Cancellation of serve_forever task causes the server to be closed.

      This method can be called if the server is already accepting connections. Only one serve_forever task can exist per one Server object.

      async def client_connected(reader, writer): # Communicate with the client with # reader/writer streams. For example: await reader.readline() async def main(host, port): srv = await asyncio.start_server( client_connected, host, port) await srv.serve_forever() asyncio.run(main('127.0.0.1', 0)) 

      New in version 3.7.

      is_serving ( ) ¶

      Return True if the server is accepting new connections.

      New in version 3.7.

      coroutine wait_closed ( ) ¶

      Wait until the close() method completes and all active connections have finished.

      List of socket-like objects, asyncio.trsock.TransportSocket , which the server is listening on.

      Changed in version 3.7: Prior to Python 3.7 Server.sockets used to return an internal list of server sockets directly. In 3.7 a copy of that list is returned.

      Event Loop Implementations¶

      asyncio ships with two different event loop implementations: SelectorEventLoop and ProactorEventLoop .

      By default asyncio is configured to use SelectorEventLoop on Unix and ProactorEventLoop on Windows.

      class asyncio. SelectorEventLoop ¶

      An event loop based on the selectors module.

      Uses the most efficient selector available for the given platform. It is also possible to manually configure the exact selector implementation to be used:

      import asyncio import selectors class MyPolicy(asyncio.DefaultEventLoopPolicy): def new_event_loop(self): selector = selectors.SelectSelector() return asyncio.SelectorEventLoop(selector) asyncio.set_event_loop_policy(MyPolicy()) 

      class asyncio. ProactorEventLoop ¶

      An event loop for Windows that uses “I/O Completion Ports” (IOCP).

      class asyncio. AbstractEventLoop ¶

      Abstract base class for asyncio-compliant event loops.

      The Event Loop Methods section lists all methods that an alternative implementation of AbstractEventLoop should have defined.

      Examples¶

      Note that all examples in this section purposefully show how to use the low-level event loop APIs, such as loop.run_forever() and loop.call_soon() . Modern asyncio applications rarely need to be written this way; consider using the high-level functions like asyncio.run() .

      Hello World with call_soon()¶

      An example using the loop.call_soon() method to schedule a callback. The callback displays «Hello World» and then stops the event loop:

      import asyncio def hello_world(loop): """A callback to print 'Hello World' and stop the event loop""" print('Hello World') loop.stop() loop = asyncio.new_event_loop() # Schedule a call to hello_world() loop.call_soon(hello_world, loop) # Blocking call interrupted by loop.stop() try: loop.run_forever() finally: loop.close() 

      A similar Hello World example created with a coroutine and the run() function.

      Display the current date with call_later()¶

      An example of a callback displaying the current date every second. The callback uses the loop.call_later() method to reschedule itself after 5 seconds, and then stops the event loop:

      import asyncio import datetime def display_date(end_time, loop): print(datetime.datetime.now()) if (loop.time() + 1.0)  end_time: loop.call_later(1, display_date, end_time, loop) else: loop.stop() loop = asyncio.new_event_loop() # Schedule the first call to display_date() end_time = loop.time() + 5.0 loop.call_soon(display_date, end_time, loop) # Blocking call interrupted by loop.stop() try: loop.run_forever() finally: loop.close() 

      A similar current date example created with a coroutine and the run() function.

      Watch a file descriptor for read events¶

      Wait until a file descriptor received some data using the loop.add_reader() method and then close the event loop:

      import asyncio from socket import socketpair # Create a pair of connected file descriptors rsock, wsock = socketpair() loop = asyncio.new_event_loop() def reader(): data = rsock.recv(100) print("Received:", data.decode()) # We are done: unregister the file descriptor loop.remove_reader(rsock) # Stop the event loop loop.stop() # Register the file descriptor for read event loop.add_reader(rsock, reader) # Simulate the reception of data from the network loop.call_soon(wsock.send, 'abc'.encode()) try: # Run the event loop loop.run_forever() finally: # We are done. Close sockets and the event loop. rsock.close() wsock.close() loop.close() 
      • A similar example using transports, protocols, and the loop.create_connection() method.
      • Another similar example using the high-level asyncio.open_connection() function and streams.

      Set signal handlers for SIGINT and SIGTERM¶

      (This signals example only works on Unix.)

      Register handlers for signals SIGINT and SIGTERM using the loop.add_signal_handler() method:

      import asyncio import functools import os import signal def ask_exit(signame, loop): print("got signal %s: exit" % signame) loop.stop() async def main(): loop = asyncio.get_running_loop() for signame in 'SIGINT', 'SIGTERM'>: loop.add_signal_handler( getattr(signal, signame), functools.partial(ask_exit, signame, loop)) await asyncio.sleep(3600) print("Event loop running for 1 hour, press Ctrl+C to interrupt.") print(f"pid os.getpid()>: send SIGINT or SIGTERM to exit.") asyncio.run(main()) 

      Table of Contents

      • Event Loop
        • Event Loop Methods
          • Running and stopping the loop
          • Scheduling callbacks
          • Scheduling delayed callbacks
          • Creating Futures and Tasks
          • Opening network connections
          • Creating network servers
          • Transferring files
          • TLS Upgrade
          • Watching file descriptors
          • Working with socket objects directly
          • DNS
          • Working with pipes
          • Unix signals
          • Executing code in thread or process pools
          • Error Handling API
          • Enabling debug mode
          • Running Subprocesses
          • Hello World with call_soon()
          • Display the current date with call_later()
          • Watch a file descriptor for read events
          • Set signal handlers for SIGINT and SIGTERM

          Async socket exception что значит

          Уже достало перезагружать сервер. Постоянно зависает Ирбис-сервер и вываливается с ошибкой Asynchronous socket error 10061

          Помогает только убить в процесах irbis_server.exe и server_64.exe

          Помогите пожалуйста, невозможно работать

          Система Ирбис 64 версия 2010.1 D5

          Редактировано 1 раз. Последний раз 02.08.2011 14:25 пользователем newkos.

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: newkos (IP-адрес скрыт)
          Дата: 03, August, 2011 12:13

          Уважаемые разработчики, скажите пожалуйста от чего появляется эта проблема ? и как её решить, так как работать всё дальше не возможно !

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Alio (IP-адрес скрыт)
          Дата: 03, August, 2011 12:37
          Вы меняли irbis_server.ini?
          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: newkos (IP-адрес скрыт)
          Дата: 03, August, 2011 12:40
          Нет, не меняли. Прикрепил файл к сообщению
          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Alio (IP-адрес скрыт)
          Дата: 03, August, 2011 14:50

          Ошибка, о которой Вы говорите, возникает у клиента, когда НЕ ЗАСТАРТОВАН сервер.
          Эта ошибка имела место всегда или это возникло с какого-то момента?

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: newkos (IP-адрес скрыт)
          Дата: 03, August, 2011 14:54

          дело в том что сервер запущен, а ошибка начала появляться недавно, сначало редко, потом всё чаще. Ошибка появляется на клиентских АРМах после того как зависает сам сервер Ирбиса.

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Alio (IP-адрес скрыт)
          Дата: 03, August, 2011 15:45

          newkos написал(а):
          ——————————————————-
          > дело в том что сервер запущен, а ошибка начала
          > появляться недавно,
          Так что же изменилось на сервере и в сети с НЕДАВНИХ пор?
          — на это можете ответить только Вы.

          сначало редко, потом всё чаще.
          > Ошибка появляется на клиентских АРМах после того
          > как зависает сам сервер Ирбиса.

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: newkos (IP-адрес скрыт)
          Дата: 03, August, 2011 15:50
          на сервере ничего не менялось, мы перешли с Ирбис 32 на Ирбис 64, после этого и начались проблемы.
          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Alio (IP-адрес скрыт)
          Дата: 03, August, 2011 17:11

          newkos написал(а):
          ——————————————————-
          > на сервере ничего не менялось, мы перешли с Ирбис
          > 32 на Ирбис 64, после этого и начались проблемы.
          Однако. Т.е. Вы хотите сказать, что ИРБИС64 ИЗНАЧАЛЬНО так у Вас работает?

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: newkos (IP-адрес скрыт)
          Дата: 03, August, 2011 17:14
          да, только как я и писал выше сначала зависания и ошибка была редко, тепер всё чаще.
          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Alio (IP-адрес скрыт)
          Дата: 03, August, 2011 17:51

          Какие еще — кроме ИРБИСа — задачи выполняются на серверной машине? Работают ли какие-либо антивирусы на сервере?

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: newkos (IP-адрес скрыт)
          Дата: 04, August, 2011 10:19

          Alio написал(а):
          ——————————————————-
          > Какие еще — кроме ИРБИСа — задачи выполняются на
          > серверной машине? Работают ли какие-либо
          > антивирусы на сервере?

          Сервер предназначен только для обслуживания Ирбиса, на нём ещё стоит Web Ирбис и всё.

          Антивирус работает, DrWeb, но я пробовал его отключать и работать, к сожалению ничего не изменилось.

          вчера, половину дня удалось поработать без зависания, что пока радует, сегодня буду ещё наблюдать.

          П.С. Очень жаль что в лог файле сервера не ведётся более подробная запись, что б потом при зависании можно было вычислить от чего и почему.

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Alio (IP-адрес скрыт)
          Дата: 04, August, 2011 12:07
          Попробуйте — хотя бы временно — развести работу Web-ИРБИС и ИРБИС по разным машинам.
          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: newkos (IP-адрес скрыт)
          Дата: 04, August, 2011 13:07

          Alio написал(а):
          ——————————————————-
          > Попробуйте — хотя бы временно — развести работу
          > Web-ИРБИС и ИРБИС по разным машинам.

          Спасибо, попробую на пару дней развести их, о результате отпишу

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Михайленко Илья (IP-адрес скрыт)
          Дата: 04, August, 2011 19:08

          Большинство проблем, связанных с зависаниями сервера на сегодня связаны с механизмом передачи данных по сети: обрезка пакетов, неожиданный разрыв соединения и т.д. С версии 2010.1 сетевые ошибки уровня протокола tcp/ip стали показываться пользователям. Наличие таких ошибок говорит о проблемах в сети, которые администраторам необходимо решать.

          Код ошибки TCP 10061: Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение

          Логи на сервере в Вашем случае ничем бы не помогли — соединение рвется НЕ сервером или клиентом. Собственно, они даже и не догадываются что им кто-то что-то пытался отослать.

          Другой вопрос где именно это соединение рвется.

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

          Далее. Если операционная система не серверная, а клиентская (например, XP) — не забывайте про ее ограничения на кол-во соединений.

          Так же этим могут грешить сетевые железяки. Наибольшая надежность из того что я встречал у Cisco, наименьшая у dlink. Отвратительно (что удивительно — может, просто мне такие экземпляры попались) на не маршрутизируемых протоколах себя ведут baystack’и.

          Главная рекомендация — пройти по всей цепочке, по которой у Вас идет tcp пакет.

          В логах сервера ведется:
          1. краткая информация о командах
          2. Режим отладки — полностью входящие и исходящие пакеты. (Аккуратно — на каждую команду создается по 2 файла — запрос и ответ)

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Михайленко Илья (IP-адрес скрыт)
          Дата: 04, August, 2011 19:12

          Еще один момент — фаерволы. Некоторые фаерволы множественные подключения к порту 6666 воспринимают как атаку.

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Alio (IP-адрес скрыт)
          Дата: 11, September, 2011 12:38
          Хотелось бы услышать newkos — что сейчас у Вас происходит.
          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: newkos (IP-адрес скрыт)
          Дата: 11, September, 2011 12:54

          Забыл отписать в теме.

          Была проведена полная переустановка системы на сервере, после чего полная переустановка самого ирбиса и пересоздание всех словарей и баз. После чего было проведено несколько тестов, из каких ошибку выявили. Всё сводилось к тому, что у нас есть филиал в другом здании, который мы подключили где-то в начале лета к системе ирбис64, сначала всё работало отлично, а потом начались эти проблемы про которые я выше писал, но я не мог подумать, что в проблемах виноват филиал.

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

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

          Вот такие приключения.

          Редактировано 1 раз. Последний раз 11.09.2011 12:55 пользователем newkos.

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Панев Максим (IP-адрес скрыт)
          Дата: 11, September, 2011 21:01

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

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Михайленко Илья (IP-адрес скрыт)
          Дата: 11, September, 2011 23:03

          Максим, по части решения этой проблемы.
          Соединение клиента ИРБИС 64 с сервером ИРБИС 64 за рамками ЛВС, это. Как бы так сказать то помягче.
          Попробую провести параллель с более привычными системами. Представь себе сайт (например, под Joomla!) на php при условии что доступ к базе MySQL происходит через сеть интернет и доходят не все пакеты. Что бы ты сказал создавшему такой сайт? А ведь Joomla тут = клиент ИРБИС64, MySQL=Сервер ИРБИС64. И разработчиков Joomla (клиент64) то же пинать смысла нет, т.к. доступ к этой базе MySQL изначально предполагается как минимум по локальной сети. И разработчиков MySQL (сервер64) тоже пинать не за что. Да и если взять любое приложение, работающее напрямик с СУБД — запуск предполагается только в рамках ЛВС. Примеры требований систем клиент-СУБД: [www.s-market.ru]
          Посмотрите на требования, к примеру, системы 1С к каналу связи между их толстыми клиентами и MSSQL. Хотя при их финансировании и размере команды разработчиков они уже мигрировали к 3-х звенной архитектуре.

          Все же, нужно понимать различия в архитектурах двузвенной и трехзвенной. Не важно что используется в качестве СУБД: Oracle, MSSQL, ИРБИС64 или еще какая-либо СУБД. Если архитектура двузвенная (толстый клиентСУБД) — значит ЛВС. Значит требования как минимум к надежности канала связи. Скорость — это на сколько у клиента терпения хватит, но надежность канала для двузвенной архитектуры является жизненно необходимой.

          ИРБИС64 тут не исключение. У ИРБИС64 толстые клиенты, работающие с СУБД, а не с сервером приложений. Изначально, архитектурно он предназначен для работы в ЛВС. Это его системное требование. Если пользователи выходят за рамки системных требований, то этот экстрим они совершают на свой страх и риск. И еще раз повторю, будь это СУБД ИРБИС64 или Oracle — результат и требования к сети будут одинаковы.

          Как только речь заходит о приложении, работающем по сети Интернет, сразу появляется сервер приложений и заводится разговор о трехзвенной архитектуре. В самом простом виде описано тут: [ru.wikipedia.org]
          Для этого и создается ИРБИС 128.
          Тут к сети другие требования. У клиентов может быть обычное интернет соединение со всеми его прелестями — потеря пакетов, низкая скорость, сложная маршрутизация и т.д. (да хоть модем и телефонная линия!) — главное внимание — к сети между сервером приложений и СУБД. Тут варианта два: или в рамках одного сервера или надежные 100Мбит-1Гбит в зависимости от кол-ва клиентов и мощностей серверов. Активных клиентов более 50 — однозначно гигабит. Более 100 — готовьтесь к кластеризации и балансировке нагрузки (после 150 уже точно пора задумываться).

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Панев Максим (IP-адрес скрыт)
          Дата: 11, September, 2011 23:58
          Как бы так по мягче сказать :), я в курсе. Исправлять нужно
          Постоянно зависает Ирбис-сервер и вываливается с ошибкой Asynchronous socket error 10061

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

          Редактировано 1 раз. Последний раз 12.09.2011 00:00 пользователем Панев Максим.

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: lev (IP-адрес скрыт)
          Дата: 21, September, 2011 18:02

          У нас подключено 14 филиалов(филиалы начали постепенно работать с момента выхода ИРБИС клиент-сервер). С определенного момента происходит то же самое, что и у newkos. Пока решить проблему не удается — мы ее не видим. Занимаемся ей и мучаем ИРБИС или он нас. Возможно кто-то поконкретней подскажет решение этой проблемы?

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: CheGevara29 (IP-адрес скрыт)
          Дата: 03, October, 2011 14:39

          Аналогичная ситуация
          Отдел комплектования активно юзающий ИРБИС находится в филиале, сетка через местного провайдера 1Мбит
          Недавно перешли с 2008 на 2010 версию.Часто зависает сервер. при подключении выдает 10053 ошибку

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Михайленко Илья (IP-адрес скрыт)
          Дата: 03, October, 2011 16:47

          10053 — Подключение было разорвано
          10061 — Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение

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

          Мучить ИРБИС тут можно очень долго — толку будет 0. Мучить надо канал связи между клиентом и сервером.
          ИРБИС 64 предназначен для работы в локальной сети. Т.е. подразумевается надежность канала 99,99999%.

          У ИРБИС 128, к сожалению, на сегодняшний день еще нет АРМ Комплектатор. С другой стороны, комплектаторы, по идее, должны находиться рядом с отделом обработки (АРМ Каталогизатор). Почему бы не перенести сервер ИРБИС 64 к ним, в ЛВС? Зачем тянуться через интернет? Выдачу тогда можно будет запустить по АРМ Книговыдача 128 через http — 128-й на таком канале себя будет чувствовать вполне себе. Сервер приложений должен жить рядом с сервером ИРБИС 64, а вот клиенты — хоть в другом городе/стране.

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: PRM (IP-адрес скрыт)
          Дата: 03, October, 2011 16:52

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

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Михайленко Илья (IP-адрес скрыт)
          Дата: 03, October, 2011 16:54

          2Максим. Для исправления придется менять архитектуру сетевого обмена. Т.е. выносить обработку коннектов в отдельные процессы/потоки (аналогично тому, как это реализовано в Apache). А это уже будет совсем другой сервер.
          Сейчас в качестве эксперимента доделываю шлюз, который именно так и обрабатывает запросы прежде чем послать их на сервер 64-го. Заодно мониторит обе стороны — и сервер и клиентов. Но это совсем другая скорость 🙁 Для выявления проблем его использовать будет можно, для постоянной работы — нет.

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: Михайленко Илья (IP-адрес скрыт)
          Дата: 03, October, 2011 16:55
          2 RPM, Постом выше. 🙂 Не успел прочитать Ваше сообщение до отправки.
          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: newkos (IP-адрес скрыт)
          Дата: 04, October, 2011 12:24

          Михайленко Илья написал(а):
          ——————————————————-
          > Сейчас в качестве эксперимента доделываю шлюз,
          > который именно так и обрабатывает запросы прежде
          > чем послать их на сервер 64-го. Заодно мониторит
          > обе стороны — и сервер и клиентов. Но это совсем
          > другая скорость 🙁 Для выявления проблем его
          > использовать будет можно, для постоянной работы —
          > нет.

          Интересно будет протестировать такое

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: CheGevara29 (IP-адрес скрыт)
          Дата: 04, October, 2011 13:07

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

          Re: Зависает сервер с ошибкой Asynchronous socket error 10061
          Пользователь: PRM (IP-адрес скрыт)
          Дата: 05, October, 2011 14:08

          Илья Иванович, спасибо.

          У нас проблемы с временным «зависанием» сервера пока что продолжаются с различной интенсивностью: 0 — 3 раза в день.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *