Unknown error code 10055

При попытке подключения из TCP-портов, превышающее 5000, возникает ошибка WSAENOBUFS (10055)

Эта статья поможет устранить ошибку WSAENOBUFS (10055)» при попытке подключения из TCP-портов, превышающее 5000.

Применимо к: Windows Server 2012 R2, Windows 10 — все выпуски
Исходный номер базы знаний: 196271

Симптомы

При попытке настроить TCP-подключения из портов, размер которых превышает 5000, локальный компьютер возвращает следующее сообщение об ошибке WSAENOBUFS (10055):

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

Решение

В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о создании резервной копии и восстановлении реестра см. в соответствующей статье базы знаний Майкрософт:
322756 Создание резервной копии и восстановление реестра Windows

Максимальное число временных TCP-портов по умолчанию — 5000 в продуктах, включенных в раздел «Область действия». В эти продукты добавлен новый параметр. Чтобы увеличить максимальное количество временных портов, выполните следующие действия.

Откройте редактор реестра.

Найдите следующий подраздел в реестре и нажмите кнопку **Параметры:

В меню «Правка » нажмите кнопку «Создать» и добавьте следующую запись реестра:
Имя значения: MaxUserPort
Тип значения: DWORD Value data: 65534 Valid Range: 5000-65534 (decimal) Default: 0x1388 (5000 decimal) Description: This parameter controls the maximum port number that is used when a program requests any available user port from the system. Как правило, временные (кратковременные) порты распределяются между значениями 1024 и 5000 включительно. После выпуска бюллетеня по безопасности MS08-037 поведение Windows Server 2003 было изменено, чтобы более точно совпадать с поведением Windows Server 2008 и Windows Vista. Дополнительные сведения о бюллетене майкрософт по безопасности MS08-037 см. в следующих номерах статей, чтобы просмотреть статьи в базе знаний Майкрософт:

951746 MS08-037: описание обновления безопасности для DNS в Windows Server 2008, Windows Server 2003 и Windows 2000 Server (на стороне DNS): 8 июля 2008 г.

951748 MS08-037: описание обновления безопасности для DNS в Windows Server 2003, Windows XP и Windows 2000 Server (на стороне клиента): 8 июля 2008 г.

953230 MS08-037: уязвимости в DNS могут привести к спуфингу

Закройте редактор реестра и перезагрузите компьютер.

Дополнительный параметр реестра TCPTimedWaitDelay определяет, как долго закрытый порт ожидает повторного использования закрытого порта.

Дополнительные сведения

Дополнительные сведения о связанной теме см. на следующем веб-сайте Майкрософт:

https://technet.microsoft.com/library/bb726981.aspx
Дополнительные сведения о связанной теме см. в следующих номерах статей, чтобы просмотреть статьи в базе знаний Майкрософт:

314053 параметров конфигурации TCP/IP и NBT для Windows XP

Техническая поддержка x64-версий Microsoft Windows

Если оборудование пришло с уже установленной версией Microsoft Windows x64, то техническую поддержку и помощь для Windows x64 предоставляет производитель оборудования. Поскольку 64-разрядный выпуск Windows входил в комплект поставки данного оборудования, обязанности по предоставлению технической поддержки несет изготовитель оборудования. Изготовитель оборудования может устанавливать 64-разрядную версию Windows с собственными компонентами. например специальными драйверами устройств, и использовать дополнительные настройки параметров для повышения производительности оборудования. Корпорация Майкрософт предоставит достаточную помощь, если вам нужна техническая помощь в выпуске Windows x64. Однако в первую очередь следует обращаться непосредственно к изготовителю оборудования. Изготовитель обладает наилучшими возможностями по поддержке установленного им программного обеспечения. Если вы приобрели выпуск Windows x64, например Windows Server 2003 x64 отдельно, обратитесь за технической поддержкой в корпорацию Майкрософт.

Источник

Socket connect error 10055

Мой клиент делает безуспешные попытки соеденится к отсуствующему серверу каждые 3 сек (по таймеру). Если сервер запустить через некоторое время, он нормально подконектится, но если это время большое (>10 мин) то клиент тупо отказывается конектится к уже запущеному серверу. При отладке клиента я обнаружил, что при многочисленных ,безуспешных попытках подконектится, клиент вскорее генерирует exception в ответ на ClientSocket1.open. Код ошибки 10055, on API Connect. И потом при следующих попытках соединения (каждые 3 сек) через ClientSocket1.open это exception постоянно возникает. В чем дело ? Привожу фрагменты кода.

//Таймер — каждые 3 сек.
procedure TForm1.ConnectingTimerTimer(Sender: TObject);
begin
.
try
sleep(100);
ClientSocket1.open; //Генерирует ошибку через 10 мин.
except
//Вот тут происходит обработка ошибки 10055
ClientSocket1.close;
end;
end;

//Обработка ошибки, если сервер неактивен.
//Но через 10 мин. Этот код уже не будет выполнятся в ответ на ClientSocket1.open, поскольку возникает ошибка 10055.

procedure TForm1.ClientSocket1Error(Sender: TObject; Socket: TCustomWinSocket; ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode:=0;
ClientSocket1.close;
ConnectingTimer.enabled:=true;
end;

procedure TForm1.ClientSocket1Connect(Sender: TObject;
Socket: TCustomWinSocket);
begin
ConnectingTimer.enabled:=false;
end;
———————
Почему ошибка возникает ? Такое ощущение что это вина Windows.
Я нашел исходники к компоненте FTP. Вот что там написано по поводу ошибки 10055:
For an unknown reason, winsock need time to send last data buffer. Without this delay, we may end with a partial file transfer. See comments in DoPutAppendAsync function. Normally using Linger option would handle this case. But many winsock implementations will end with a 10055 error after a lot of consecutive file transfers.
Что бы это значило ? Задержка то у меня стоит sleep(100)

← →
yuravss ( 2002-02-25 12:30 ) [1]

Кстати вот нашел описание этой ошибки:

10055 is an WinSock»s (Microsoft»s TCP/IP stack implementation) error code.
What causes this bug?
WSAENOBUFS should occur when the system has not enough memory or other system resources to open new TCP/IP socket or to handle socket data. It looks like that in most cases the problem occurs when total count of opened sockets reaches some magical number. MS writes that this limit is 3976 simultaneously opened sockets but it seems that on Win9x systems the real limit is much lower.
Proxy+ uses permanently about 10-20 opened sockets (it depends on configuration, number of defined Mapped Links. ) and each client request allocates two sockets — one for client side and one for server side of connection. Because TCP/IP system doesn»t free sockets immediately when they are closed (socket remains allocated for 240 seconds after application closes it) it is possible that system will report WSAENOBUFS due to lack of free socket resources.
————-
Только я не пойму из-за чего у меня происходит переполнение сокетного буфера. Я ведь использую функцию close для сокета в случае неудачного конекта.

← →
yuravss ( 2002-02-25 20:24 ) [2]

Неужели никто не сталкивался с этой проблеммой ?
Я уже было потерял надежду.

Перекопал пол инет, но нашел в чем дело !

Оказывается в обработчике TForm1.ClientSocket1Error надо писать не ClientSocket1.close, а socket.close. Тогда все нормально. А доказательства о переполнении сокетного буфера я видел наочно
(команда: netstat -an )

Помоему проблема решена. Тему «10055 error» можно закрыть ИМХО.

Источник

Windows 2003 ODBC Issues — Error 10055

Using data integrator for ETL’s pulling data from DB2 to SQL Server, after some time, will get these odbc errors:

Communication link failure. comm rc=10055 — CWBCO1003 — Sockets error, function returned 10055

Can’t do anything with ODBC after that, have to reboot the box, and currently we just reboot the box every night at midnight to try to avoid the issue from happening.

Tried this, http://support.microsoft.com/kb/196271 but it didn’t work, almost made it worse.

There doesn’t seem to be a solution in sight. No other boxes that use ODBC get this issue that we use. Can’t reformat the box at this time, legacy stuff on it.

Has anyone seen this issue, come across it, fixed it, mitigated it?

3 Answers 3

Certainly a low-memory condition, possibly caused by the extremely common mistake of not closing DB connections. My recommendations are:

1. Examine the amount of non-paged pool memory available as the process runs. Odds are it will steadily decrease until the machine fails. This is an indicator that sockets aren’t being closed or kernel I/O buffers aren’t being freed. (unclosed sockets is more likely)
2. Check for an unknown or external Layered Service Provider (LSP) in your winsock stack via ‘net sh winsock catalog > wsockcat.txt’. Compare the output to your other Windows servers. Suspect first any providers that have been inserted into your stack that originate outside of mswsock.dll.
3. If low non-paged pool is the problem see if restarting the application or either DB server releases memory. You’re likely not using connection pooling, so ‘sp who’ and ‘list applications’ might show interesting results if some DB access layer is leaving old connections open.

If you do see the DB servers reporting a high number of idle connections in #3 you may be able to mitigate the problem by writing scripts to actively shutdown unused connections from the server side of the socket.

Источник

Socket connect error 10055

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

Client.Active:=false; Client.Active:=true; на 240 попытке возникает ошибка сокета, мол очередь сокета забита
procedure TForm1.Timer1Timer(Sender: TObject);
begin
if ClientSocket1.Socket.Connected = false then
begin
ClientSocket1.Active:=false;
ClientSocket1.Active:=true;
end;
end;
Нужно чтобы клиент быстро определял Сервер активен или нет.
К примеру: Сервер работает, клиент установил с ним связь, но тут сервак падает, и не происходит события OnDisconnect, и необходимо отловить неактивность сервера.

← →
Digitman ( 2003-06-05 14:14 ) [1]

Timer1.Active := False; // начальное значение

делаем АСИНХРОННУЮ (. ) попытку соединения

в обработчике OnError() :

ErrorCode := 0; // ошибка нас не интересует
Socket.Disconnect(Socket.SocketHandle); // освободим ресурсы
Timer1.Active := True; // стартуем таймер

в обработчике OnTimer() :

Timer1.Active := False; // останов таймера
ClientSocket1.Open; // повторяем попытку соединения

← →
ALeXiuS ( 2003-06-05 19:41 ) [2]

uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
Buttons, ScktComp, ToolWin, ComCtrls, StdCtrls, ExtCtrls;

type
TForm1 = class(TForm)
Memo1: TMemo;
StatusBar1: TStatusBar;
ClientSocket1: TClientSocket;
Timer1: TTimer;
procedure ClientSocket1Connect(Sender: TObject;
Socket: TCustomWinSocket);
procedure ClientSocket1Read(Sender: TObject; Socket: TCustomWinSocket);
procedure ClientSocket1Error(Sender: TObject; Socket: TCustomWinSocket;
ErrorEvent: TErrorEvent; var ErrorCode: Integer);
procedure Timer1Timer(Sender: TObject);
procedure FormShow(Sender: TObject);
private
< Private declarations >
Server:String;
ClientName:String;
public
< Public declarations >
end;

var
Form1: TForm1;
i : integer =0;
j : integer =0;
implementation

procedure TForm1.FormShow(Sender: TObject);
begin
Timer1.Enabled:=false;
Timer1.Interval:=5000;

if ClientSocket1.Active then ClientSocket1.Active:=false;
ClientSocket1.Address:=»10.10.10.1″;
ClientSocket1.Port:=1024;
ClientSocket1.ClientType:=ctNonBlocking;
ClientSocket1.Active:=true;

procedure TForm1.ClientSocket1Connect(Sender: TObject;
Socket: TCustomWinSocket);
begin
with ClientSocket1 do
StatusBar1.Panels[0].Text := «Подсоединились к: » + Socket.RemoteHost +
» IP: » + Socket.RemoteAddress;
end;

procedure TForm1.ClientSocket1Read(Sender: TObject;
Socket: TCustomWinSocket);
begin
Memo1.Lines.add( Socket.ReceiveText );
end;

procedure TForm1.ClientSocket1Error(Sender: TObject;
Socket: TCustomWinSocket; ErrorEvent: TErrorEvent;
var ErrorCode: Integer);
begin
inc(i);
Memo1.Lines.Add(«Ошибка соединения: » + Server +» ERROR CODE :»+IntToStr(ErrorCode));
StatusBar1.Panels[0].Text := «Ошибка соединения по ERROR CODE » + IntToStr(i)+» раз. «;
ErrorCode:=0;
<по совету Digitman»a>
ClientSocket1.Socket.Disconnect(ClientSocket1.Socket.Handle);
end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
if ClientSocket1.Socket.Connected = false then
begin
ClientSocket1.Close;
inc(j);
Memo1.Lines.Add(«Ошибка соединения по времени , пробую «+IntToStr(j)+» раз. «);
ClientSocket1.Open;
end;
end;
end.
// CUT END============================================
Сделал так и ничего не получается, в конечном итоге всегда вылетает 10055(An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.)
Может кто подскажет что надо сделать, что бы эта фигня работала.
Заранее огромное спасибо.

← →
Digitman ( 2003-06-06 08:20 ) [3]

procedure TForm1.Form Create(Sender: TObject);
begin
Timer1.Enabled:=false; // . установить в design-time
Timer1.Interval:=5000;

ClientSocket1.Active:=false; // . установить в design-time
ClientSocket1.Address:=»10.10.10.1″;
ClientSocket1.Port:=1024;
ClientSocket1.ClientType:=ctNonBlocking;
ClientSocket1.Active:=true;

procedure TForm1.ClientSocket1Connect(Sender: TObject;
Socket: TCustomWinSocket);
begin
with ClientSocket1 do
StatusBar1.Panels[0].Text := «Подсоединились к: » + Socket.RemoteHost +
» IP: » + Socket.RemoteAddress;
end;

procedure TForm1.ClientSocket1Read(Sender: TObject;
Socket: TCustomWinSocket);
begin
Memo1.Lines.add( Socket.ReceiveText );
end;

procedure TForm1.ClientSocket1Error(Sender: TObject;
Socket: TCustomWinSocket; ErrorEvent: TErrorEvent;
var ErrorCode: Integer);
begin
inc(i);
Memo1.Lines.Add(«Ошибка соединения: » + Server +» ERROR CODE :»+IntToStr(ErrorCode));
StatusBar1.Panels[0].Text := «Ошибка соединения по ERROR CODE » + IntToStr(i)+» раз. «;
ErrorCode:=0;
Socket.Disconnect(Socket.Handle);
Timer1.Enabled:=True; // . через заданный интервал таймер возобновит попытку соединения
end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
Timer1.Enabled:=false; // отключим таймер
inc(j);
Memo1.Lines.Add(«Ошибка соединения, пробую «+IntToStr(j)+» раз. «);
ClientSocket1.Open;
end;

← →
ALeXiuS ( 2003-06-06 10:14 ) [4]

Это конечно хорошо но на 251 попытке соединения та же ошибка 10055

← →
ALeXiuS ( 2003-06-06 13:06 ) [6]

Все РАБОТАЕТ.
УРА.
Огромное спасибо DIGITMAN»у

Источник

← →
yuravss
 
(2002-02-25 04:45)
[0]

← →
yuravss
 
(2002-02-25 12:30)
[1]

← →
yuravss
 
(2002-02-25 20:24)
[2]

I’m investigating some issues with winsock 10055 errors on a chain of custom applications (some of which we control, some not) and was hoping to get some advice on techniques to troubleshoot the problem.

No buffer space available.
    An operation on a socket could not be performed because the system 
    lacked sufficient buffer space or because a queue was full.

From research, non-paged pool and ports seem to be the only resources which can cause this error. Is there another resource which might cause 10055 errors?

Currently, we have perfmon counters setup on the applications and non-paged pool usage looks low in most circumstances. Open TCP connections looks low and I am unaware of another way to monitor ports.

Since it only happens in production, we are unable to use more invasive counters. Though it would still be interesting to hear other solutions. I’m sure other people could use the information.

Is there some other tool or procedure you would recommend to diagnose which application is causing the issue?

UPDATE:

The platform is windows server 2003 x86 with the /3G switch. For reference, x86 generally has 256mb of NPP storage, /3G lowers it to 128mb. In general, you’d want to avoid this configuration for avoiding NPP problems. (reference)

We have source to one application. I have written pretty elaborate testing harnesses trying to reproduce the behavior to no avail.

As mentioned, the problem only happens in production. As such, packet monitoring has been avoided. We currently have performance counters setup that monitors NPP, threads, network traffic, etc. Since perfmon’s interval is 1sec, you could have microbursts that come and go within that window. There is somewhat subjective evidence that this isn’t the problem however.

The basic situation is that the other side of the connection says that it has closed the connection due to errors with 10055 as the code. NPP (and performance in general) looks stable prior to disconnects, which points to some other resource being the cause.

UPDATE:

I’d also reiterate that the original questions pertain to diagnosis, not solutions. I still don’t have a clear answer on what causes 10055 errors. Checking drivers and hardware and reinstalling operating systems is great, but it sidesteps the original question.

Симптомы Ошибка 10055 — kCFErrorDomainWinSock: 10055

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

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

(Только для примера)

Причины kCFErrorDomainWinSock: 10055 — Ошибка 10055

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

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

Методы исправления

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

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

Обратите внимание: ни ErrorVault.com, ни его авторы не несут ответственности за результаты действий, предпринятых при использовании любого из методов ремонта, перечисленных на этой странице — вы выполняете эти шаги на свой страх и риск.

Ошибка socket error 10055

Expert

Регистрация: 07-Мар-07
Местонахождение: Russian Federation
Статус: Offline
Количество сообщений: 1986 Параметры сообщения

Цитировать Ответить Тема: Ошибка socket error 10055
Добавлено: 25-Май-09 в 16:49

Тип события: Предупреждение
Источник события: Traffic Inspector Server
Категория события: Traffic Inspector service
Код события: 21504
Дата: 25.05.2009
Время: 16:07:46
Пользователь: Н/Д
Компьютер: HOSTSERV
Описание:
[HTTP proxy] socket error 10055 — No buffer space available

после этой ошибки перестал работать сервер терминалов , только он использует прокси (кеш отключен).
По сетевой статистике , сессии на прокси сервер шли и по 53 порту и по 80 , но в мизерном количестве и интернета не было.

нашел пост с аналогичной проблемой

Причина ошибки — в системе открыто очень много сокетов. По умолчанию лимит где-то на 4000 (на вскидку, мог и подзабыть).

Откройте Диагностика, Сокеты и поглядите, что там есть. Сколько сокетов и какие процессы их открыли.

единственный сервис , который в данный момент так открыл сокеты это DNS.
Пересеклось с темой:
http://forum.smart-soft.ru/forum_posts.asp?TID=16750&KW= DNS+UDP&PN=0&TPN=1

Настроил DNS на минимально открытые сокеты , буду тестировать.

Раньше проблема была по аналогии такой же
http://forum.smart-soft.ru/forum_posts.asp?TID=18574&PN= 3
с начала ошибок 1450 отваливался Сервер терминалов, затем все остальные клиенты, обновил драйвера на сетевухи. Сервер проработал чуть больше недели с момента рестарта той проблемы и до начала этой.

Больших списочных фильтров не имею.
Ребутнули сервер.

Зы отчеты с ссылкой на форум выслал.
ЗЗЫ. Очень не нравится , когда на форуме не отвечает сапорт.

ТИ 2.0.1.725 + W2k8 (550 клиентов/до 380 активных, канал 200 мегабит)

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

Источник

Windows socket error 10055 on api connect

Мой клиент делает безуспешные попытки соеденится к отсуствующему серверу каждые 3 сек (по таймеру). Если сервер запустить через некоторое время, он нормально подконектится, но если это время большое (>10 мин) то клиент тупо отказывается конектится к уже запущеному серверу. При отладке клиента я обнаружил, что при многочисленных ,безуспешных попытках подконектится, клиент вскорее генерирует exception в ответ на ClientSocket1.open. Код ошибки 10055, on API Connect. И потом при следующих попытках соединения (каждые 3 сек) через ClientSocket1.open это exception постоянно возникает. В чем дело ? Привожу фрагменты кода.

//Таймер — каждые 3 сек.
procedure TForm1.ConnectingTimerTimer(Sender: TObject);
begin
.
try
sleep(100);
ClientSocket1.open; //Генерирует ошибку через 10 мин.
except
//Вот тут происходит обработка ошибки 10055
ClientSocket1.close;
end;
end;

//Обработка ошибки, если сервер неактивен.
//Но через 10 мин. Этот код уже не будет выполнятся в ответ на ClientSocket1.open, поскольку возникает ошибка 10055.

procedure TForm1.ClientSocket1Error(Sender: TObject; Socket: TCustomWinSocket; ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode:=0;
ClientSocket1.close;
ConnectingTimer.enabled:=true;
end;

procedure TForm1.ClientSocket1Connect(Sender: TObject;
Socket: TCustomWinSocket);
begin
ConnectingTimer.enabled:=false;
end;
———————
Почему ошибка возникает ? Такое ощущение что это вина Windows.
Я нашел исходники к компоненте FTP. Вот что там написано по поводу ошибки 10055:
For an unknown reason, winsock need time to send last data buffer. Without this delay, we may end with a partial file transfer. See comments in DoPutAppendAsync function. Normally using Linger option would handle this case. But many winsock implementations will end with a 10055 error after a lot of consecutive file transfers.
Что бы это значило ? Задержка то у меня стоит sleep(100)

← →
yuravss ( 2002-02-25 12:30 ) [1]

Кстати вот нашел описание этой ошибки:

10055 is an WinSock»s (Microsoft»s TCP/IP stack implementation) error code.
What causes this bug?
WSAENOBUFS should occur when the system has not enough memory or other system resources to open new TCP/IP socket or to handle socket data. It looks like that in most cases the problem occurs when total count of opened sockets reaches some magical number. MS writes that this limit is 3976 simultaneously opened sockets but it seems that on Win9x systems the real limit is much lower.
Proxy+ uses permanently about 10-20 opened sockets (it depends on configuration, number of defined Mapped Links. ) and each client request allocates two sockets — one for client side and one for server side of connection. Because TCP/IP system doesn»t free sockets immediately when they are closed (socket remains allocated for 240 seconds after application closes it) it is possible that system will report WSAENOBUFS due to lack of free socket resources.
————-
Только я не пойму из-за чего у меня происходит переполнение сокетного буфера. Я ведь использую функцию close для сокета в случае неудачного конекта.

← →
yuravss ( 2002-02-25 20:24 ) [2]

Неужели никто не сталкивался с этой проблеммой ?
Я уже было потерял надежду.

Перекопал пол инет, но нашел в чем дело !

Оказывается в обработчике TForm1.ClientSocket1Error надо писать не ClientSocket1.close, а socket.close. Тогда все нормально. А доказательства о переполнении сокетного буфера я видел наочно
(команда: netstat -an )

Помоему проблема решена. Тему «10055 error» можно закрыть ИМХО.

Источник

Windows socket error 10055 on api connect

Мой клиент делает безуспешные попытки соеденится к отсуствующему серверу каждые 3 сек (по таймеру). Если сервер запустить через некоторое время, он нормально подконектится, но если это время большое (>10 мин) то клиент тупо отказывается конектится к уже запущеному серверу. При отладке клиента я обнаружил, что при многочисленных ,безуспешных попытках подконектится, клиент вскорее генерирует exception в ответ на ClientSocket1.open. Код ошибки 10055, on API Connect. И потом при следующих попытках соединения (каждые 3 сек) через ClientSocket1.open это exception постоянно возникает. В чем дело ? Привожу фрагменты кода.

//Таймер — каждые 3 сек.
procedure TForm1.ConnectingTimerTimer(Sender: TObject);
begin
.
try
sleep(100);
ClientSocket1.open; //Генерирует ошибку через 10 мин.
except
//Вот тут происходит обработка ошибки 10055
ClientSocket1.close;
end;
end;

//Обработка ошибки, если сервер неактивен.
//Но через 10 мин. Этот код уже не будет выполнятся в ответ на ClientSocket1.open, поскольку возникает ошибка 10055.

procedure TForm1.ClientSocket1Error(Sender: TObject; Socket: TCustomWinSocket; ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode:=0;
ClientSocket1.close;
ConnectingTimer.enabled:=true;
end;

procedure TForm1.ClientSocket1Connect(Sender: TObject;
Socket: TCustomWinSocket);
begin
ConnectingTimer.enabled:=false;
end;
———————
Почему ошибка возникает ? Такое ощущение что это вина Windows.
Я нашел исходники к компоненте FTP. Вот что там написано по поводу ошибки 10055:
For an unknown reason, winsock need time to send last data buffer. Without this delay, we may end with a partial file transfer. See comments in DoPutAppendAsync function. Normally using Linger option would handle this case. But many winsock implementations will end with a 10055 error after a lot of consecutive file transfers.
Что бы это значило ? Задержка то у меня стоит sleep(100)

← →
yuravss ( 2002-02-25 12:30 ) [1]

Кстати вот нашел описание этой ошибки:

10055 is an WinSock»s (Microsoft»s TCP/IP stack implementation) error code.
What causes this bug?
WSAENOBUFS should occur when the system has not enough memory or other system resources to open new TCP/IP socket or to handle socket data. It looks like that in most cases the problem occurs when total count of opened sockets reaches some magical number. MS writes that this limit is 3976 simultaneously opened sockets but it seems that on Win9x systems the real limit is much lower.
Proxy+ uses permanently about 10-20 opened sockets (it depends on configuration, number of defined Mapped Links. ) and each client request allocates two sockets — one for client side and one for server side of connection. Because TCP/IP system doesn»t free sockets immediately when they are closed (socket remains allocated for 240 seconds after application closes it) it is possible that system will report WSAENOBUFS due to lack of free socket resources.
————-
Только я не пойму из-за чего у меня происходит переполнение сокетного буфера. Я ведь использую функцию close для сокета в случае неудачного конекта.

← →
yuravss ( 2002-02-25 20:24 ) [2]

Неужели никто не сталкивался с этой проблеммой ?
Я уже было потерял надежду.

Перекопал пол инет, но нашел в чем дело !

Оказывается в обработчике TForm1.ClientSocket1Error надо писать не ClientSocket1.close, а socket.close. Тогда все нормально. А доказательства о переполнении сокетного буфера я видел наочно
(команда: netstat -an )

Помоему проблема решена. Тему «10055 error» можно закрыть ИМХО.

Источник