Понятно. Что мешает использовать несколько соединений с целевым сервером?

Здравствуйте, Gomes, Вы писали:

G>Понятно. Что мешает использовать несколько соединений с целевым сервером?

Видимо, сервер уже есть какой есть, и трогать его нельзя.

да, друзья спасибо огромное, именно так и есть — сервер удаленный этот он и один коннект только дает,

perf13, да, суть в этом, я уже каркас такой и заложил с очередями-контейнерами для накопления данных от/для сокета , вот действительно асинхронность куречить синхронными вставками не хочется, осмысливаю сейчас Ваш совет — как он ложится

да, вообщем, все по делу, действительно в моем случае все равно по любому требуется реализовать "один вызов WSASend() — одно завершение" и помогает удержать эту 'линейку' промежуточная очередь-контейнер данных для отправки в сокет

Здравствуйте, Pepel, Вы писали:

P>да, вообщем, все по делу, действительно в моем случае все равно по любому требуется реализовать "один вызов WSASend() — одно завершение" и помогает удержать эту 'линейку' промежуточная очередь-контейнер данных для отправки в сокет

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

Здравствуйте, maxlosyam, Вы писали:

M>Здравствуйте, Pepel, Вы писали:

P>>да, вообщем, все по делу, действительно в моем случае все равно по любому требуется реализовать "один вызов WSASend() — одно завершение" и помогает удержать эту 'линейку' промежуточная очередь-контейнер данных для отправки в сокет

M>рекомендую использовать TransmitPackets, он пошустрее
M>ну а вообще пакеты в твоем случае надо фреймовать, т.е удаленном серверу передаешь не просто пакеты друг за другом, а каждый пакет вкладываешь во фрейм с инфой о том чей это пакет и какой он длинны, и на удаленном уже пакеты из фремов извлекаешь как хочешь.
M>но если удаленный сервер изменить нельзя, то фигово

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

по ходу возник вопрос : интересует аналитика сбоев при работе с удаленными хостами будь то клиенты либо сервера,

для сокетов моего приложения, соединенных с удаленным клиентом (AcceptEx()), и сокетов, соединенных с удаленным сервером (ConnectEx()), хотелось бы отслеживать ситуацию неуспешного завершения вызова, означающее, что другая сторона просто недоступна, т.е. "я все делаю правильно, мои вызовы верны, но тот берег недоступен" и тогда для сокета соединенного с клиентском — сворачивать его и работать дальше, для сокета соединенного с сервером — по таймауту пытаться восстановить соединение

посмотрел Windows Sockets Error Codes, вот похоже подмножество кодов, означающее то, что мне интересно :

WSAENETDOWN Network is down.
WSAENETUNREACH Network is unreachable.
WSAENETRESET Network dropped connection on reset.
WSAECONNABORTED Software caused connection abort.
WSAECONNRESET Connection reset by peer.
WSAETIMEDOUT Connection timed out.
WSAECONNREFUSED Connection refused.
WSAEHOSTDOWN Host is down.
WSAEHOSTUNREACH No route to host.
WSAEDISCON Graceful shutdown in progress.

но это много, на какие именно возвраты стоит ориентироваться ?

ок, вот еще нужен совет :

потоков в пуле несколько и если на одном происходит ошибка — останавливать ли остальные и идти на останов сервиса либо 'лететь на одном крыле', т.е. пока хоть один поток пашет — логировать ошибки остальных потоков и не реагировать на них ?

Здравствуйте, Аноним, Вы писали:

А>ок, вот еще нужен совет :

А>потоков в пуле несколько и если на одном происходит ошибка — останавливать ли остальные и идти на останов сервиса либо 'лететь на одном крыле', т.е. пока хоть один поток пашет — логировать ошибки остальных потоков и не реагировать на них ?

что-то непонятно именно о чем вопрос, если об

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

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

ок, спасибо

>не надо делать из программы живучего монстра

да, вообщем грамотное предложение, подумал вот, действительно лучше свернуть сервис после ЛЮБОГО сбоя, потому как тяжело гарантированно установить класс сбоя и процесс после такого рода 'умных' анализаторов может долго 'работать' на самом деле не работая — а это дичь которая похуже остановов/рестартов

люди добрые, тут ерунда какаят с этим ConnectEx() :

Requirements
Client: Included in Windows XP.
Server: Included in Windows Server 2003.
Header: Declared in Mswsock.h.
Library: Use Mswsock.lib

Ни под Win2000 ни под Vista MS Visual C++ (Studio 2003 и 2005) в упор не находят функцию, это ... это слов нет ..

error C3861: 'ConnectEx': identifier not found, even with argument-dependent lookup

да уж, c DisconnectEx() таже песня

варианты рассматриваю :

1. отказываться от поддержки Win2000

2. использовать connect/(shutdown+closesocket) — порнография, у меня весь остальной движок асинхронный на IOCP

нужен совет

Здравствуйте, Pepel, Вы писали:

P>люди добрые, тут ерунда какаят с этим ConnectEx() :

P>Requirements
P>Client: Included in Windows XP.
P>Server: Included in Windows Server 2003.
P>Header: Declared in Mswsock.h.
P>Library: Use Mswsock.lib

P>Ни под Win2000 ни под Vista MS Visual C++ (Studio 2003 и 2005) в упор не находят функцию, это ... это слов нет ..

P>error C3861: 'ConnectEx': identifier not found, even with argument-dependent lookup

её и все Ex IOCP функции нужно получать в рантайме.

The function pointer for the ConnectEx function must be obtained at run time by making a call to the WSAIoctl function with the SIO_GET_EXTENSION_FUNCTION_POINTER opcode specified. The input buffer passed to the WSAIoctl function must contain WSAID_CONNECTEX, a globally unique identifier (GUID) whose value identifies the ConnectEx extension function. On success, the output returned by the WSAIoctl function contains a pointer to the ConnectEx function. The WSAID_CONNECTEX GUID is defined in the Mswsock.h header file.

это сделано специально из-за LSP драйверов, если функции экспортировать напрямую, то из-за способа их реализации о поддержке динамического изменения LSP каталога просто не может быть и речи. поэтому сделали так.
в wsock32.dll есть экспорт на AcceptEx, но где-то непомню где у микрософта написано, что напрямую ей пользоваться нельзя. потому что внутри просто тупо идет получение ее поинтера в рантайме, как в привиденном примере ниже, и только потом она вызвается, поэтому лучше сразу самому получить поинтер на функцию, так работает быстрее.

вот пример из моей проги:

#include <Mswsock.h>
LPFN_CONNECTEX            m_pConnectEx = 0;

GUID guidconnectEx = WSAID_CONNECTEX;

SOCKET hSocket = CreateSocket(); // ну socket или WSASocket, просто для WSAIoctl нужен сокет :)

// skipped

if(!m_pConnectEx)
{
    dwT = 0;
    nRet = WSAIoctl(hSocket,SIO_GET_EXTENSION_FUNCTION_POINTER,&guidConnectEx,sizeof(GUID)
        ,&m_pConnectEx,sizeof(m_pConnectEx),&dwT,0,0);
    assert(nRet != SOCKET_ERROR);
    assert(m_pConnectEx);
    if(nRet == SOCKET_ERROR || !m_pConnectEx) 
    {
        Close(hSocket);
        return false;
    }
}

// и все тоже самое для всех функций

// skipped

Close(hSocket);

Здравствуйте, maxlosyam, Вы писали:

M>Здравствуйте, Pepel, Вы писали:

P>>люди добрые, тут ерунда какаят с этим ConnectEx() :

P>>Requirements
P>>Client: Included in Windows XP.
P>>Server: Included in Windows Server 2003.
P>>Header: Declared in Mswsock.h.
P>>Library: Use Mswsock.lib

P>>Ни под Win2000 ни под Vista MS Visual C++ (Studio 2003 и 2005) в упор не находят функцию, это ... это слов нет ..

P>>error C3861: 'ConnectEx': identifier not found, even with argument-dependent lookup

M>её и все Ex IOCP функции нужно получать в рантайме.

упс погнал, да на w2k прийдется забить.

Здравствуйте, Pepel, Вы писали:

P>да уж, c DisconnectEx() таже песня

P>варианты рассматриваю :

P>1. отказываться от поддержки Win2000

P>2. использовать connect/(shutdown+closesocket) — порнография, у меня весь остальной движок асинхронный на IOCP

P>нужен совет

ничего не поделаешь, поддежрка этих функций начинается с xp и 2003

Спасибо !

maxlosyam, вопрос тогда : ладно, AcceptEx я уже вяжу статически через lib, по Вашему совету ConnectEx и DisconnectEx — получу их точки входа в рантайме приведенным способом, но как быть с поддержкой Win2000 ? т.е. на ней я не смогу получить точки входа этих функций ? похоже нет, т.е. отказ от поддержки приложением это версии ОС, так ? Вы как делаете в таком случае ?

понял, спасибо

Здравствуйте, Pepel, Вы писали:

P>понял, спасибо

селяви а что кто-то ещё использует w2k как серверную ос? 2003 имхо на порядок лучше, и х64 и IOCP api все есть
IOCP это серверная фишка, талмуды от микрософта говорят о кашерности написания серверов на IOCP
а AcceptEx тоже рекомендую получать в рантайме.

да вообщем продакшн система будет Win2003 Server, но я сижу на Win2000 Professional, поэтому вот думаю сегодня на 2003 шустренько со всеми студиями соскочить и там бодать задачу дальше

Здравствуйте, Pepel, Вы писали:

P>да вообщем продакшн система будет Win2003 Server, но я сижу на Win2000 Professional, поэтому вот думаю сегодня на 2003 шустренько со всеми студиями соскочить и там бодать задачу дальше

можно просто на WinXP x64, таж самая 2003 только пользовательская.