Winsock и Winsock`и.

[Proxy]

Начал писать свой протокол передачи мгновенных сообщений (Цель: сделать экономичный к трафу протокол, простой в изучении). Написал клиентскую часть (процентов 90), начал писать серверную часть, но столкнулся с тем, что не понимаю как к одному винсоку сервера приконнектить много клиентов. Действую по следующему алгоритму:
Сервер слушает
Клиент пытается подключиться
Сервер выключает прослушивание порта
Сервер подтверждает подключение
Работает с клиентом
...

А вот как приконнектить ещё клиенты?
(Винсок юзаю из-за наглядности, API конечно лучше, но сервер мне нужен только для выявления ошибок в работе клиента, для доработки и испытания. Сервер в данном случае является только прототипом, потом будет вполностью переписан на другом языке).

[iGrok]

Массив винсоков +1 "Слушатель".
Сервер получает запрос на соединение, инитит новый винсок в массиве, и соеднияет его с клиентом. После чего продолжает слушать.

[Proxy]

Т.е. одним портом на сервере не обойтись? Надо много портов выделять? На каждый клиент свой? Это разве реально?
Или много винсоков могут юзать один порт? А вынь не напишет разве, что порт уже занят?

[AntonGV]

Вот пример

[|kerish|]

На мой взгляд этот способ несет в себе два недостатка:

Первый - это ограничение на количество одновременных соединений чуть меньше 32767.

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

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

[ale_x]

Количество занимаех портов зависит от типа подключения. Например если UPD то для каждого подключения юзается свой порт. Создается связь между клиентом-сервером, резервируется порт. Пока соединение не будет разорвано, то доступ к порту другими программами будет закрыт.
Если TCP соединение то тогда один порт, просто создается сокет между клиентом-сервером. А что бы подлюкчать много клиентов: создашь массив winsocka на сервере и при подключении в массив добавляешь +1 и все. Так при подключении каждого будет создавать свой winsock.

[|kerish|]

Количество занимаех портов зависит от типа подключения. Например если UPD то для каждого подключения юзается свой порт. Создается связь между клиентом-сервером, резервируется порт. Пока соединение не будет разорвано, то доступ к порту другими программами будет закрыт.
Если TCP соединение то тогда один порт, просто создается сокет между клиентом-сервером. А что бы подлюкчать много клиентов: создашь массив winsocka на сервере и при подключении в массив добавляешь +1 и все. Так при подключении каждого будет создавать свой winsock.

Уважаемый, Вы уж звиняйте, но Вы абсолютно не в теме.
Все написанное вами - бред шизофреника.
Даже не берусь комментировать.

[Proxy]

Вобщем сколько клиентов - столько портов, а иначе никак?
Т.е. после резервирования порта под клиент придётся отслеживать в рантайме свободные порты, а если таковых нет, то сообщать клиенту IP другого сервера, поддерживающего данный сервис? А как в этом случае избежать цикличных переадресовок? Это задача клиента или сервера? Или же переадресация вообще не нужна (т.е. нет потов - иди на) и пусть клиент сам ищет другие серверы?

[alibek]

Это уже тебе решать.
Можешь сделать так, что когда число клиентов превышает определенный лимит, то новые клиенты подключаются, им высылается сообщение "Нет свободных портов" и они отключаются сервером. Клиенту будет приятна такая забота, но тогда твое приложение потенциально уязвимо для DDoS-атаки.
Можно просто игнорировать все запросы, если количество подключений достигло лимита. Но тогда клиентам будет не очень удобно, это будет означать долгую попытку подключения и ошибку по таймауту, по неизвестной причине. Но зато это более безопасно для сервера.

[|kerish|]

Я всё же не могу понять зачем юзать TCP?
Чем UDP не угодил?
Ну лишний байт будет приходить для отчетности доставки, зато обо всех проблемах с портами можно забыть.

[alibek]

А ты почитай об ограничениях UDP и подумай.
UDP не всегда подходит.

[|kerish|]

alibek Ну и какое же у него ограничение кроме ненадежности?

Поясни, плз, просто я сейчас как раз пишу приложение и решил использовать именно UDP протокол.

Как я уже сказал доставка пакета легко проверяется возвращением байта к примеру.

[alibek]

Маршрутизация. Фрагментация.

[|kerish|]

Почитал по теме, спасибо.

Но вобщем-то не нашел ничего страшного.

Огромное число игр используют UDP для передачи данных, тот же Conter-Strike.

[iGrok]

Потеря пакета в игре - не так страшна.

[alibek]

А что еще кроме контр-страйка?
Вообще-то для мультиплейера чаще используют TCP, чем UDP. И даже тот же контрстрайк также использует TCP-соединение, уже не помню, для чего.

Также попробуй по UDP отправить пакет данных размером в 2Кб.
В сетевой игре потребности в этом нет, пакеты данных там небольшие. А в сетевом приложении может и потребоваться.
Также попробуй пообщаться по UDP с компьютером, который находится за NAT.

[|kerish|]

Я понял, буду юзать TCP.

А какой максимальный размер пакета, который может послать/принять WinSock за один раз?

[alibek]

Зависит от конфигурации машины и сети.
Обычно 1400 с чем-то байт.
TCP сам фрагментируется, доставляется и собирается, тебе об этом беспокоится не надо. А с UDP тебе придется реализовать подобный механизм самостоятельно.
Кроме того, хотя UDP и натится, но порой с этим бывают всякие проблемы. Поэтому UDP вполне оправдан в локальных сетях, а в глобальных надо вначале изучить вопрос.