Здравствуйте, vvv848165@ya.ru, Вы писали:
v> а скока максимум можно на один IP:port подключить клиентов? v> и с чем это связано ? v> Спасибо!
TCP соединение определяется четырьмя параметрами: { src ip, src port, dst ip, dst port }. Длина IP составляет 128 бит, длина порта 16 бит. Это теоретический максимум. В реальности все ограничится памятью / cpu.
Да нее, все проще.
Когда сервер принимает клиента он создает socket для него.
Смотрим, что такое socket:
В Linux/Unix это тип int (самый мерзкий сишный тип )
А что такое int? Это число зависящее от разрядности ОС/компилятора.
В 16-ти разрядном варианте int это числа в диапазоне −32767, +32767.
Так как отрицательные сокеты быть не могут, значит максимальный теоретический предел 32767 клиента.
В 32-х разрядном варианте int это числа в диапазоне −2 147 483 647, +2 147 483 647,
аналогично, максимальный теоретический предел 2 147 483 647 клиента.
На счет 64-х битной реализации библиотеки сокетов в Nix-ах я не в курсах, но если вдруг, то
по аналогии теорпердел 9 223 372 036 854 775 807 клиента.
Смотрим теперь, что там в Windows.
В Windows у нас (у них) socket это тип:
typedef UINT_PTR SOCKET
А что такое в Windows тип UINT_PTR, это опять же есть зависимость от разрядности Windows/компилятора
AB> Длина IP составляет 128 бит
Это про IPv6? дак там куча резервных значений ... AB> В реальности все ограничится памятью / cpu.
вот то то и оно — от ресурсов вобще не зависит...
через неблокирующие или асинхронные можно спокойно 30k соединений обрабатывать при этом памяти <30 mb потребует ... а если не все активно данные пересылают — то загрузка проца 0%
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>Здравствуйте, Dimatec, Вы писали:
D>>Да нее, все проще.
VYR>опять любитель IPv6 ... VYR>да хоть int256 всё равно сокеты в IPv4 тока 16 битные (да ещё они и заняты бывают)
блин!!! мало того что запутал дак и с мысли сбил
на сервере статический ip и заданный порт (они используются для связи)
а у клиентов свой ip (иногда рандомный, а иногда ip подсети ...) и порт рандомный (OS и маршрутизаторы выбирает свободные порты для коннекта)
так что если все клиенты не пойдут через один маршрутизатор упора в разрядность порта вобще не будет
Здравствуйте, vvv848165@ya.ru, Вы писали:
D>>Да нее, все проще.
VYR>опять любитель IPv6 ... VYR>да хоть int256 всё равно сокеты в IPv4 тока 16 битные (да ещё они и заняты бывают)
В TCP ничего не сказано про сокеты. Ничего не мешает написать реализацию, где они хоть 256-битные будут.
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>>Здравствуйте, Dimatec, Вы писали:
D>>>Да нее, все проще.
VYR>>опять любитель IPv6 ... VYR>>да хоть int256 всё равно сокеты в IPv4 тока 16 битные (да ещё они и заняты бывают)
VYR>блин!!! мало того что запутал дак и с мысли сбил
VYR>на сервере статический ip и заданный порт (они используются для связи) VYR>а у клиентов свой ip (иногда рандомный, а иногда ip подсети ...) и порт рандомный (OS и маршрутизаторы выбирает свободные порты для коннекта) VYR>так что если все клиенты не пойдут через один маршрутизатор упора в разрядность порта вобще не будет
VYR>подтвердите если это так! спасибо!
Ахаха, чувак у тебя путаница в голове, про что такое сетевое программирование.
Начни с классики, а то я тебе про тру Ивана, а ты про IPv6 да маршрутизаторы ))))))))
Две ключевые книги, хватит на века ))) :
Стивенс — UNIX. Разработка сетевых приложений.
Джонс — Программирование в сетях Microsoft Windows.
Ключевая вещь, которая проливает свет на твой вопрос это функция socket(), и то,
как ее использует приложение в качестве сервера,
и самая соль, значения какого типа она возвращает.
А вот потом можешь попридираться, что мол, скорее всего,
не сможет современная ОС выделить 4 млрд хендлов на сокеты, (один клиент — один хендл (сокет)) и т.п.
и уж тем более 18 млрд экса гига мега штук ))).
И что вопрос про максимальное количество клиентов не такой максимальный, и это должно ванговаться автоматически )))
Здравствуйте, vsb, Вы писали:
vsb>В TCP ничего не сказано про сокеты. Ничего не мешает написать реализацию, где они хоть 256-битные будут.
ну в курсе ... есть даже такие организации что IP адресацией вобще не пользуются (у них вобще свои протоколы) например у КБСП протокол КОМИН
если в маршрутизаторе будут фильтроваться пакеты с 256-битн портами то он их придушит на X — потому-что не надо стандарты менять по которым вся сеть работает
Здравствуйте, Dimatec, Вы писали:
D>Когда сервер принимает клиента он создает socket для него. D>Смотрим, что такое socket: D>Смотрим, что такое socket: D>В Linux/Unix это тип int (самый мерзкий сишный тип ) D>А что такое int? Это число зависящее от разрядности ОС/компилятора.
Смотрим в книгу, видим фигу.
А что если этот инт это номер бита в битовой карте ? А что если она ещё и sparsed ? ВНЕЗАПНО все рассуждения посыпались.
Поэтому надо немного понимать, что там, "под капотом".
Сокет, прежде всего, объект ядра. Кроме того, в Linux он ссылается на 4 других объекта.
Два из которых обязательны (file, sock). Причём file — довольно крупный объёкт.
Поэтому, в самом идеальном случае, даже если забыть о фрагментации SLUB-ов, каждый сокет это байт эдак 128 в пространстве 64 битного ядра (реально — намного больше).
Здравствуйте, vvv848165@ya.ru, Вы писали:
vsb>>В TCP ничего не сказано про сокеты. Ничего не мешает написать реализацию, где они хоть 256-битные будут.
VYR>ну в курсе ... есть даже такие организации что IP адресацией вобще не пользуются (у них вобще свои протоколы) например у КБСП протокол КОМИН
VYR>если в маршрутизаторе будут фильтроваться пакеты с 256-битн портами то он их придушит на X — потому-что не надо стандарты менять по которым вся сеть работает
Ты не путай порты и сокеты. Это разные вещи. Порт в TCP занимает 2 байта. А сокет это сущность конкретной реализации в конкретной ОС.
Здравствуйте, Буравчик, Вы писали:
vsb>>В TCP ничего не сказано про сокеты. Ничего не мешает написать реализацию, где они хоть 256-битные будут.
Б>Сокеты надо как-то идентифицировать. На уровне TCP/IP (v4) для этого есть 96 бит.
Б>TCP выделяет 16 бит для порта отправителя/получателя. Б>IPv4 выделяет 32 бита для адреса отправителя/получателя
Б>Как ты из этого сделаешь 256 бит?
Во-первых есть IPv6. Во-вторых из 96 битов сделать 256 — ума много не надо, хоть нулями забей, хоть мусором. Про 256 битов это так, передёргивание, 64, конечно, хватит для всего.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Dimatec, Вы писали:
D>>Когда сервер принимает клиента он создает socket для него. D>>Смотрим, что такое socket: D>>Смотрим, что такое socket: D>>В Linux/Unix это тип int (самый мерзкий сишный тип ) D>>А что такое int? Это число зависящее от разрядности ОС/компилятора.
IID>Смотрим в книгу, видим фигу. IID>А что если этот инт это номер бита в битовой карте ? А что если она ещё и sparsed ? ВНЕЗАПНО все рассуждения посыпались.
IID>Поэтому надо немного понимать, что там, "под капотом". IID>Сокет, прежде всего, объект ядра. Кроме того, в Linux он ссылается на 4 других объекта. IID>Два из которых обязательны (file, sock). Причём file — довольно крупный объёкт.
IID>Поэтому, в самом идеальном случае, даже если забыть о фрагментации SLUB-ов, каждый сокет это байт эдак 128 в пространстве 64 битного ядра (реально — намного больше).
Ну чтоб фиги не видеть прочти в своих книжках с крутыми названиями хоть одну главу хоть раз.
Да приложению все равно на что ссылается сокет, хоть на указатель на кучу у которой стока байт внутри, что ого-го.
Вопрос в том сколько таких ссылок можно создать, а не сколько байт у этой ссылки под капотом.
Подкапот как раз уменьшает количество этих ссылок. Потому что у ядра скорее память кончится,
выделять под каждый сокет свои подкапотные структуры, да ворочить их в каком нибудь планировщике,
чем 32-разрядный int подойдет к свое верхней границе.
Здравствуйте, vvv848165@ya.ru, Вы писали:
v> AB> Длина IP составляет 128 бит v> Это про IPv6? дак там куча резервных значений ...
IPv4 устарел и прошлый век же и да, это оценка сверху.
v> AB> В реальности все ограничится памятью / cpu. v> вот то то и оно — от ресурсов вобще не зависит... v> через неблокирующие или асинхронные можно спокойно 30k соединений обрабатывать при этом памяти <30 mb потребует ... а если не все активно данные пересылают — то загрузка проца 0%
Держать тысячи активных TCP соединений особого практического смысла нет — должна выполняться какая-то работа. Например, современный TCP почти всегда идет в связке с TLS, а это нехило так кушает CPU (особенно TLS handshake). Если мы говорим про HTTP/RPC, то выполняется дополнительная работа по упаковке и роутингу трафика и т.д. Т.е. RAM / CPU практически всегда будут лимитирующим фактором в сравнении с потолком возможного числа соединений.
Здравствуйте, Anton Batenev, Вы писали:
AB>Держать тысячи активных TCP соединений особого практического смысла нет — должна выполняться какая-то работа. Например, современный TCP почти всегда идет в связке с TLS, а это нехило так кушает CPU (особенно TLS handshake). Если мы говорим про HTTP/RPC, то выполняется дополнительная работа по упаковке и роутингу трафика и т.д. Т.е. RAM / CPU практически всегда будут лимитирующим фактором в сравнении с потолком возможного числа соединений.
Почему практического смысла нет? Классический пример — чат сервер. Сидит в чате миллион клиентов. Реально из них пишет что-то в данный момент сто человек. Ну пинги там ещё сто человек в каждый конкретный момент отрабатывают. Но чат должен работать моментально, поэтому нужно держать соединение до каждого из клиентов.
Здравствуйте, vsb, Вы писали:
vsb> Почему практического смысла нет? Классический пример — чат сервер. Сидит в чате миллион клиентов. Реально из них пишет что-то в данный момент сто человек. Ну пинги там ещё сто человек в каждый конкретный момент отрабатывают. Но чат должен работать моментально, поэтому нужно держать соединение до каждого из клиентов.
Возможно я криво выразился. Имелось ввиду, что держать соединения только ради соединений нет смысла — должна производиться какая-то полезная работа, а даже тривиальная работа чат сервера приведет к исчерпанию ресурсов по CPU/RAM (а возможно и пропускной способности конкретного линка) сильно быстрее чем по лимиту сокетов.
Здравствуйте, Anton Batenev, Вы писали:
AB>Возможно я криво выразился. Имелось ввиду, что держать соединения только ради соединений нет смысла — должна производиться какая-то полезная работа, а даже тривиальная работа чат сервера приведет к исчерпанию ресурсов по CPU/RAM (а возможно и пропускной способности конкретного линка) сильно быстрее чем по лимиту сокетов.
"Имелось ввиду, что держать соединения только ради соединений нет смысла" — а смысл почти всегда в этом
в ~30% случаях клиент держит соединение и через определёный момент времени отправляет (или сервер) что с ним всё нормально
в ~70% держат соединение клиент и сервер (и отправляют пустые команды друг другу) только ради своевременного обнаружения обрыва связи (особенно если нужна надёжность) — если просто выдрать шнур из маршрутизатора ошибка иногда приходит слишком с задержкой.
)
и да, это оценка сверху.