WSARecv или ReadFile?

← →
Демо © (2009-10-29 23:56) [0]

В WinSock2 появились новые функции - WSARecv и WSASend.
Как я понимаю, кроме кроссплатформенности они ничем не лучше старых ReadFile и WriteWile.

Просьбы высказать мысли по этому поводу.
Имеются ли какие-то преимущества у новых функций?

← →
Демо © (2009-10-30 00:00) [1]

PS. Использую перекрытый ввод/вывод с IOCP.

← →
Сергей М. © (2009-10-30 00:19) [2]

> кроме кроссплатформенности

Какая к лешему "кроссплатформенность", если WinSock ?)

← →
Демо © (2009-10-30 00:24) [3]

> Сергей М. © (30.10.09 00:19) [2]
> > кроме кроссплатформенностиКакая к лешему "кроссплатформенность",
> если WinSock ?)

-)

Ну да. сорри.
Кроссплатформенностью с дуру назвал разные версии winddows.

← →
Демо © (2009-10-30 00:25) [4]

И всё же?

← →
Сергей М. © (2009-10-30 00:34) [5]

> с дуру

Пишется слитно.

> И всё же?

На параметр lpFlags поглазей)

← →
Сергей М. © (2009-10-30 00:47) [6]

> назвал разные версии winddows

Все версии новее 3.11 так или иначе поддерживают WS2.

← →
Демо © (2009-10-30 01:30) [7]

> На параметр lpFlags поглазей)

А он для семейства протоколов TCP имеет значение?

← →
Сергей М. © (2009-10-30 08:14) [8]

Имеет.
Не только, но и в том числе.

← →
Демо © (2009-10-30 12:46) [9]

Судя по MSDN, флаг lpFlags может быть комбинацией из трёх бит:

MSG_PEEK
MSG_OOB
MSG_PARTIAL

Для поточно-ориентированных сокетов остаётся только MSG_PEEK и MSG_OOB.

Конечно, это плюс к WSARecv.
Спасибо за наводку.

Есть ли кроме этого плюсы?

← →
Сергей М. © (2009-10-30 12:52) [10]

> Есть ли кроме этого плюсы?

А разве этого не достаточно ?
Ведь Read/WriteFile[Ex] не даст тебе такой функциональности, если она требуется..

← →
Демо © (2009-10-30 12:56) [11]

> Сергей М. © (30.10.09 12:52) [10]
> > Есть ли кроме этого плюсы?А разве этого не достаточно
> ?Ведь Read/WriteFile[Ex] не даст тебе такой функциональности,
> если она требуется..

Спасибо, Сергей.
Как раз вот на эту инфу с флагом не обратил внимания.

← →
Сергей М. © (2009-10-30 13:03) [12]

И опять же касаемо кроссплатформенности - как раз по этим соображениям не следует пользовать ни WSA-функции ни Read/WriteFile.

Только send[to]/recv[from] - они обязаны присутствовать на любой платформе, поддерживающей базовую функциональность гнезд Беркли.

← →
Демо © (2009-10-30 13:49) [13]

> Сергей М. © (30.10.09 13:03) [12]
> И опять же касаемо кроссплатформенности - как раз по этим
> соображениям не следует пользовать ни WSA-функции ни Read/WriteFile.
>

Ну что касаемо кроссплатформенности - тут у меня проблем нет.
Проект будет работать на платформе Windows.

Поэтому свой выбор сделаю всё-таки в пользу WSA-функций, видимо.

← →
Polevi © (2009-10-30 14:00) [14]

WSA позволяют работать с цепочкой буферов, иногда это удобно

← →
Сергей М. © (2009-10-30 14:06) [15]

+ к [14]

WSAAccept позволяет организовать настоящее условное акцептирование запросов на соединение

← →
Демо © (2009-10-30 14:10) [16]

> Polevi © (30.10.09 14:00) [14]
> WSA позволяют работать с цепочкой буферов, иногда это удобно

У меня не будет обмена данными большого размера, планируется обмен короткими пакетами.

На сервере хочу предусмотреть возможность работы под хорошей нагрузкой, поэтому SOCKET IO OVERLAPPED + IOCP.
На клиенте можно попроще - просто SOCKET IO OVERLAPPED.

Конечно, не факт, что сервер будет очень уж популярен, но предусмотреть нужно.

Просто наконец-то взялся за проект, который мечтаю уже 10 лет сделать.
Надеюсь, что наконец-то воплощу в реальность.

← →
Демо © (2009-10-30 14:11) [17]

> Сергей М. © (30.10.09 14:06) [15]
> + к [14]WSAAccept позволяет организовать настоящее условное
> акцептирование запросов на соединение

WSAAccept я уже реализовал именно таким способом.

Вопрос по этому поводу:

Возможно ли на этом уровне уменьшить угрозу от SYN-атак?

← →
Демо © (2009-10-30 14:12) [18]

PS.
Обнаружил ошибки в портированном WINSOCK2.PAS от Алексея Коншина...

← →
Polevi © (2009-10-30 14:20) [19]

Я использую его модуль, проблем не было

← →
Демо © (2009-10-30 14:22) [20]

> Polevi © (30.10.09 14:20) [19]
> Я использую его модуль, проблем не было

Проблема возникла при реализации WSAAccept с LPCONDITIONPROC.

← →
Сергей М. © (2009-10-30 14:25) [21]

> Возможно ли на этом уровне уменьшить угрозу от SYN-атак?

Нет.
Этим должен заниматься файрвол.

В winsock2.pas:

function WSAAccept( s : TSocket; addr : TSockAddr; addrlen : PInteger; lpfnCondition : LPCONDITIONPROC; dwCallbackData : DWORD ): TSocket; stdcall;

TSockAddrIn = packed record case Integer of 0: (sin_family : u_short; sin_port : u_short; sin_addr : TInAddr; sin_zero : array[0..7] of Char); 1: (sa_family : u_short; sa_data : array[0..13] of Char) end; PSockAddrIn = ^TSockAddrIn; TSockAddr = TSockAddrIn; PSockAddr = ^TSockAddr; SOCKADDR = TSockAddr; SOCKADDR_IN = TSockAddrIn;

Вот так работает:

function WSAAccept( s: TSocket; addr:PSockAddr; addrlen: PInteger; lpfnCondition: LPCONDITIONPROC; dwCallbackData: DWORD): TSocket; stdcall; external "ws2_32.dll";

А описание структур взял из стандартного winsock.pas.

Всего-то один параметр...

> Сергей М. © (30.10.09 14:25) [21]
> > Возможно ли на этом уровне уменьшить угрозу от SYN-атак?
> Нет.Этим должен заниматься файрвол.

Понятно. Значит не буду этим заморачиваться...

> Всего-то один параметр

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

> > Всего-то один параметрНу бывают маленькие неприятности,
> куда ж без них)

Ага... а я полдня бился над WSAAccept -))

Эх, если бы знать, что это единственный недочёт...

> я полдня бился над WSAAccept

Я встроил его в TIdCustomTCPServer за час.
Лажа с параметром всплыла и была исправлена при первом же тестовом прогоне)

> Сергей М. © (30.10.09 14:36) [28]
> > я полдня бился над WSAAcceptЯ встроил его в TIdCustomTCPServer
> за час.Лажа с параметром всплыла и была исправлена при первом
> же тестовом прогоне)

А я, к сожалению, впервые использовал WSAAccept и понадеялся на портированный модуль, искал у себя ошибки.

Ну выскажи Коншину своё "фи", если тебе от этого полегчает)

WSARecv или ReadFile? Найти похожие ветки