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

А>Один порт работает на прием данных, то есть источник приема один на одном порту.
А>На втором порте сидит куча клиентов, которые только принемают данные.

Т.е. сервер создает два порта. К одному подключается один клиент, к другому куча.
Да, создаем два экземпляра сервера на разных портах. Есть функция перечисления подключений, по ней и передаём принятое.
С двумя портами — это обязательное условие? Проще же с одним.

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

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

А>>Один порт работает на прием данных, то есть источник приема один на одном порту.
А>>На втором порте сидит куча клиентов, которые только принемают данные.

G>Т.е. сервер создает два порта. К одному подключается один клиент, к другому куча.
G>Да, создаем два экземпляра сервера на разных портах. Есть функция перечисления подключений, по ней и передаём принятое.
G>С двумя портами — это обязательное условие? Проще же с одним.

Нет с двумя совершенно не обязательно...

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

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

А>Нет с двумя совершенно не обязательно...

Если только один может отправлять данные, то всё упрощается.

А>Ок, я принял сообщение, как разослать его всем кроме того что отправил ? делать вектор и заносить туда данные при подключении клиентов, а потом перебирать из, или это уже есть в библе ? Простите, просто API не очень ясный :)

Ккккак это АПИ не ясный?? API.chm -- яснее некуда ;)
Функция PServer_EnumConnections

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

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

А>>Готов взять, сразу вопрос, чем она хороша ?

G>Простая, быстрая, надёжная. Короче — самая крутая. Даже денег за неё не прошу

http://www.serverframework.com/

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

А>http://www.serverframework.com/

Не совсем понял что вы этим хочите сказать.

The Core Framework £3,100

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

G>Бери мою библиотеку.
G>prostoserver.com

оффтоп:
покупают?

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

S>оффтоп:
S>покупают?

Не часто, но да. Исходники тоже.

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

S>Организовать ретранслятор. То есть сервер, к которому подключены клиенты посредством TCP. Сервер принимает данные от одного клиента, и просто передает их всем остальным. Данные строковые, от 1кб до 4-х. В секунду может быть до 5 таких пакетов. Текущий вариант, сделан на c# на ассинхронных сокетах. Все прекрасно пока клиентов 50 — 60 ... но как только клиентов становится более 100, то начинаются безбожные задержки в получении данных (раздача сервера) иногда пакеты задерживаются до 10 минут !!! Что крайне не приемлемо, нужно по возсожности почти мгновенная передача.

Давайте посчитаем. 100 клиентов присылают каждый по 5 раз по 4 кб, т.е. около 2 МБ (в секунду!). Сервер должен отправить эти же данные остальным 99 клиентам (от каждого всем), т.е. 2 * 99 = 198 мегабайт в ту же секунду . Или я что-то неправильно понял, или вы слишком многого хотите? На тестовых машинах сетевые карты гигабитные или сотки?

Если я всё же понял задачу правильно, то достигнутый предел в 50-60 клиентов это весьма неплохой результат.

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

А>Давайте посчитаем. 100 клиентов присылают каждый по 5 раз по 4 кб, т.е. около 2 МБ (в секунду!).

У него один клиент шлёт.

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

G>У него один клиент шлёт.

Не похоже, судя по коду полученное от клиента сообщение отсылается всем остальным клиентам:

unsigned int __stdcall _thread_start_proc(void *arg)
{
//пропуск кода
    while (1) {   
        std::string r;

        recve_line( s, r );

        user_counter = 0;
        time(&start);
        if (r.empty()) 
            break;
        
        for (std::list<SOCKET>::iterator it = clients.begin(); it != clients.end(); it++) {
            if (*it != s) 
                send(*it, r.c_str(), r.length(), 0);
            user_counter++;
        }        
        system("cls");
        time (&end);
        dif = difftime (end,start);
        log( "I spent %.4f sec that would send data to %d users\n", dif, user_counter);
    }
//пропуск кода
}

int main( int argc, char **argv )
{
//пропуск кода
    while( true )
    {
        if((_socket = accept(listener, (sockaddr *)&addr, &size)) != INVALID_SOCKET)
        {
            printf("accept: %d\n", _socket);
            ioctlsocket(_socket, FIONBIO, &argp);

            unsigned int thid;
            printf("pass socket: %d\n",_socket);
            _beginthreadex(0, 0, _thread_start_proc, (void *)&_socket, 0, &thid);
        }
        Sleep(1000);
    }
//пропуск кода
}

Тоесть получается данные от любого клиента отсылаются всем остальным клиентам.
ТС все верно?

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

А>Не похоже, судя по коду полученное от клиента сообщение отсылается всем остальным клиентам:

Так точно.

А>Тоесть получается данные от любого клиента отсылаются всем остальным клиентам.

Нет. Получается что от одного всем. На этом был акцент. Не надо придумывать.

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

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

G>>У него один клиент шлёт.

А>Не похоже, судя по коду полученное от клиента сообщение отсылается всем остальным клиентам:

Так точно, но источник у меня один. То есть один шлет данные, все остальные получают.

А>Тоесть получается данные от любого клиента отсылаются всем остальным клиентам.
А>ТС все верно?
Да верно, по коду так. (просто логика кода, эдакий большой чат сервер) но на деле, у меня один источник, все остальные молча принимают данные.

Получилось что-нибудь?

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

S>Всем добрый день,

...

S>Прошу помощи. Если возможно в чем проблема в данном подходе, и есть ли более удачные варианты реализации мгновенной передачи данных от одного клиента всем. UDP не подходит. Так как клиенты сидят в интернете, а не за одной сеткой.

Посмотрите в сторону IGMP multicast.
Основным недостатком будет являться обязательная поддержка малтикаста всеми промежуточными маршрутизаторами и сетевыми картами,
но как вариант для задачи "удачные варианты реализации мгновенной передачи данных от одного клиента всем" вполне решение.
Там же IGMP snooping.

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

G>Получилось что-нибудь?
Нет, все еще попытки сделать что-то "нормальное". В том числе с помощью твоей библы

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

5er>Здравствуйте, stronciy77, Вы писали:

S>>Всем добрый день,

5er>...

S>>Прошу помощи. Если возможно в чем проблема в данном подходе, и есть ли более удачные варианты реализации мгновенной передачи данных от одного клиента всем. UDP не подходит. Так как клиенты сидят в интернете, а не за одной сеткой.

5er>Посмотрите в сторону IGMP multicast.
5er>Основным недостатком будет являться обязательная поддержка малтикаста всеми промежуточными маршрутизаторами и сетевыми картами,
5er>но как вариант для задачи "удачные варианты реализации мгновенной передачи данных от одного клиента всем" вполне решение.
5er>Там же IGMP snooping.
Не знаю тонкостей IGMP, но для меня такой вариант к сожалению исключен, потому что клиенты (которые слушают) разбросаны по всему миру. Если бы сидели за одной сеткой, сделал бы UDP рассылку и всех делов...

На вскидку:

BOOL CALLBACK OnConnect( PCONNECTION pConnection )
{
    // Постим для всех.
    PServer.PostRecv( pConnection, pConnection->pbBuffer, BUF_SIZE, NULL );
}

BOOL CALLBACK EnumConnectionsProc( PCONNECTION pConnection, PVOID pvParam )
{
    // Получаем подключение-источник.
    PCONNECTION pSource = (PCONNECTION) pvParam;

    // Шлём собственно.
    PServer.PostSend( pConnection, pSource->pbBuffer, (DWORD) pSource->pvPerConnectionUserData, NULL );
}

BOOL CALLBACK OnRecv( PCONNECTION pConnection, PIO_DATA pIoData )
{
    //
    // Возможно необходима проверка что приняли всё.
    //

    // Сохраняем количество принятых байт.
    pConnection->pvPerConnectionUserData = (PVOID) pIoData->dwBytesTransferred;

    //
    // Перечисляем подключения. Параметром передаем подключение-источник.
    //
    // Тут надо понимать, что мы занимаем целый поток из пула на перечисление и отправку.
    // Можно избавиться, используя UserPool, но, усложняя логику.
    //
    PServer.EnumConnections( EnumConnectionsProc, (PVOID) pConnection );

    // Всё отправлено.
    // Постим следующий запрос на приём.
    PServer.PostRecv( pConnection, pConnection->pbBuffer, BUF_SIZE, NULL );
}

BOOL CALLBACK OnSend( PCONNECTION pConnection, PIO_DATA pIoData )
{
    // Возвращем TRUE наверно.
}

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

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

C>> В итоге ты получаешь замкнутый цикл типа while(1){}, вот тебе и загрузка CPU
N_C>В принципе, маленького вызова sleep с параметром 10 должно хватить для снижения загрузки CPU до приемлемых процентов... Не?
Sleep в Win32 в любом случае делает задержку не менее 55 мс. т.к. пользуется обычным таймером величина тика которого равна 55 мс., я считаю применение Sleep — это не выход из положения в данных ситуациях. За это время, пока находимся в Sleep, можно вычитать из сокета большую порцию данных.

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

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

ACD>>я только что тестировал свой проект под нагрузкой — ок. В чём то схоже.
ACD>>Сделал на boost::asio.
ACD>>На "чистых" сокетах я тоже раньше делал, но тут быстрее получается. Если не считать чтения манула по asio.
ACD>>Но с нуля на сокетах ещё больше читать надо и дольше отлаживать.

S>Ясно, я тоже сомтрел на boost но там 60 метров библиотек ... Не суть, для дела не жалко, а как у него с "быстрой" разадчей, то есть если есть куча медленных и куча быстрых клиентов ?

В любом случае boost использует Win API. Есть вероятность конечно что ихняя реализация обмена в неблокирующем режиме будет качественней, чем ваша, но где тут заблудиться то можно в вашей задаче когда на WinSock делать, равнозначно как в 3-х березах заблудиться.

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

M>вот тут http://www.tenouk.com/Module41.html есть пример сервера на select, все делается в одном потоке. просто почитайте поищите про select.
Вообще select введен для совместимости с кодами UNIX. Для Win родное — это OVERLAPED, а для улутшения работы с OVERLAPED применяется IOCP.
В принципе когда у машины один процессор с одним ядром, то при хорошей реализации однопоточное приложение будет работать быстрее, чем многопоточное. Только реализовать такое приложение сложнее, чем многопоточное. Это я к вопросу о тысячах подключений и по потоку на обработку каждого подключения.