проблема — сервер в Linux, не могу сделать чтобы он поддерживал только одно соединение. Проверяю на 2 клиентах — оба коннектятся.
Хотя accept в сервере не запускается до тех пор пока не обслужится текущее соединение. Но второй клиент коннектится и без accept. А мне нужно чтобы его connect вылетал с ошибкой. Рассмотрел 2 варианта — поставить в listen backlog=1 (не помогло), и закрывать слушающий порт на время обработки соединения (пока не пробовал).
Подскажите что можно сделать

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

I>проблема — сервер в Linux, не могу сделать чтобы он поддерживал только одно соединение. Проверяю на 2 клиентах — оба коннектятся.
I>Хотя accept в сервере не запускается до тех пор пока не обслужится текущее соединение. Но второй клиент коннектится и без accept. А мне нужно чтобы его connect вылетал с ошибкой. Рассмотрел 2 варианта — поставить в listen backlog=1 (не помогло), и закрывать слушающий порт на время обработки соединения (пока не пробовал).
I>Подскажите что можно сделать

После accept() закрой прослушиваемый серверный сокет. После обработки снова его открой. И линух тут не причем

Здравствуйте, Infineon, Вы писали:
I>Рассмотрел 2 варианта — поставить в listen backlog=1 (не помогло)

Я честно говоря, не встречал, не пробывал и не уверен, что будет работать, но может попробывать установить backlog = 0? По логике, backlog — это количество соединений, ожидающий обработки. Т.е в Вашем примере ( backlog=1 ) после accept еще одно соединение будет установлено и удержено до следующего вызова accept.

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

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

TC>Я честно говоря, не встречал, не пробывал и не уверен, что будет работать, но может попробывать установить backlog = 0?

Зависит от реализации. Рихтер приводил фактические значения при попытке установить backlog = 0. Почти везде (т.е. во всех распространенных UNIX'ах) получалось 1, в Линуксе — 3. Так что автору явно не поможет.

P.S. Как в Windows — тебе виднее
MSDN молчит...

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

TC>Я честно говоря, не встречал, не пробывал и не уверен, что будет работать, но может попробывать установить backlog = 0? По логике, backlog — это количество соединений, ожидающий обработки. Т.е в Вашем примере ( backlog=1 ) после accept еще одно соединение будет установлено и удержено до следующего вызова accept.

Когда TCP/IP API только появилось действительно соблюдалось что-то подобное тому, что вы сказали, то есть backlog определял очередь входящих соединений. В последнее время, как я понял, это не совсем так. Это что-то подобное размеру очереди входящих соединений. Поэтому, самый действенный способ, который здесь предложили — это закрывать после успешного accept серверное соединение. После обработки запроса снова открывать его.

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

MC>Рихтер...

Тьфу... Заработался. Стивенс конечно же. Да и не сам Стивенс, а кто-там-модернизировал-его-Network-Programming-до-третьего-издания.

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

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

TC>>Я честно говоря, не встречал, не пробывал и не уверен, что будет работать, но может попробывать установить backlog = 0?

MC>Зависит от реализации. Рихтер приводил фактические значения при попытке установить backlog = 0. Почти везде (т.е. во всех распространенных UNIX'ах) получалось 1, в Линуксе — 3. Так что автору явно не поможет.

Надо будет на досуге проверить эти самые "3" для линуха, что-то не срастается с маном

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

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

TC>>Я честно говоря, не встречал, не пробывал и не уверен, что будет работать, но может попробывать установить backlog = 0? По логике, backlog — это количество соединений, ожидающий обработки. Т.е в Вашем примере ( backlog=1 ) после accept еще одно соединение будет установлено и удержено до следующего вызова accept.

_>Когда TCP/IP API только появилось действительно соблюдалось что-то подобное тому, что вы сказали, то есть backlog определял очередь входящих соединений. В последнее время, как я понял, это не совсем так. Это что-то подобное размеру очереди входящих соединений. Поэтому, самый действенный способ, который здесь предложили — это закрывать после успешного accept серверное соединение. После обработки запроса снова открывать его.

В man listen для Linux в разделе замечания написано про backlog (теперь две очереди).

По поводу способа с реопеном — не особо корректный, но условия задачи не ясны (возможно bad design в самой задаче, не понятно почему нельзя работать обычным образом), поэтому и предложил такой выход, в нем навскидку одна проблема точно есть — если между accept() и close() случиться второе соединение, то оно обломиться у клиента уже после connect() на read/write.