Асинхронные сокеты

← →
prodex (2008-03-14 06:04) [0]

Сокращенный код:
...
ServSock:=Socket(AF_Inet,SOCK_STREAM,IPPROTO_TCP);
Addr.sin_family:=AF_Inet;
Addr.sin_addr.S_addr:=InAddr_Any;
Addr.sin_port:=HToNS(4000);
FillChar(Addr.sin_zero,SizeOf(Addr.sin_zero),0);
Bind(ServSock,Addr,SizeOf(Addr));
Listen(ServSock,SOMAXCONN);
WSAAsyncSelect(ServSock,Handle,WM_SSocketEvent,FD_Read or FD_Accept or FD_Close or FD_Connect);
...
//Отправка сообщения
...
Addr.sin_family:=AF_Inet;
Addr.sin_addr.S_addr:=Inet_Addr("localhost");
Addr.sin_port:=HToNS(4000);
Connect(ServSock,Addr,SizeOf(Addr));
FStr:=TFileStream.Create("D:\111.xls",fmOpenRead);
SetLength(OutBuf,FStr.Size);
FStr.Position:=0;
FStr.ReadBuffer(OutBuf[0],FStr.Size);
n:=FStr.Size;
Send(ServSock,OutBuf[0],n,0);
...

Так вот при инициализации сокета как SOCK_STREAM после connect(...) WSAGetLastError возвращает ошибку WSAEINVAL : "The socket is already bound to an address." (Как указано в справке). Но при инициализации как SOCK_DGRAM все работает без проблем. И ещё вопрос: при SOCK_STREAM данные тож передаются пакетами не более какого-то размера?

← →
Сергей М. © (2008-03-14 10:19) [1]

> Connect(ServSock

Серверное гнездо никогда не является инициатором соединения, это право и обязанность клиентского гнезда.

> при SOCK_STREAM данные тож передаются пакетами не более
> какого-то размера?

У потока (SOCK_STREAM) нет размера, поток он и есть поток.

А буфер передачи действительно имеет фиксированный размер, по умолчанию он = 8к

← →
grisme (2008-03-14 11:51) [2]

> //Отправка сообщения... Addr.sin_family:=AF_Inet; Addr.sin_addr.
> S_addr:=Inet_Addr("localhost"); Addr.sin_port:=HToNS(4000);
> Connect(ServSock,Addr,SizeOf(Addr)); FStr:=TFileStream.
> Create("D:\111.xls",fmOpenRead); SetLength(OutBuf,FStr.Size);
> FStr.Position:=0; FStr.ReadBuffer(OutBuf[0],FStr.Size);
> n:=FStr.Size; Send(ServSock,OutBuf[0],n,0);...

во-первых, ^^^ странные действия. какой-такой connect для ServSock? O_o и, тем более, Send для ServSock.
во-вторых, Ketmar меня правильно пнул, асинхронный режим -- это полная бяка. работай в блокирующем режиме + threads

← →
Сергей М. © (2008-03-14 12:02) [3]

> асинхронный режим -- это полная бяка

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

← →
DVM © (2008-03-14 16:32) [4]

> асинхронный режим -- это полная бяка

Зато этот режим лучше всего укладывается в событийную идеологию Windows.

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

← →
SpellCaster (2008-03-14 17:42) [5]

Да, но дебажить все это дело - убиться можно. К тому же процесс подключения, например, к сокс-проксе превращается в некий клубок макарон %).

> дебажить все это дело - убиться можно

Да ты что ?!)

А мужики-то и не знают !..)...

Синхронные, ассинхронные, все зависит от задачи...

> prodex (14.03.08 06:04)

http://www.citforum.ru/book/cook/winsock.shtml

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

Асинхронные сокеты Найти похожие ветки