Понятно, что это erlang+elixir. Но все же при физическом ограничении в ~60т. сокетов как это возможно?
Т.е. я понимаю про non-blocking IO, c10k и т.д., но с10М как? Как возможно наплодить такое кол-во сокетов на одной машине?
Здравствуйте, Sharov, Вы писали:
S>Понятно, что это erlang+elixir. Но все же при физическом ограничении в ~60т. сокетов как это возможно? S>Т.е. я понимаю про non-blocking IO, c10k и т.д., но с10М как? Как возможно наплодить такое кол-во сокетов на одной машине?
Откуда берётся ограничение в 60т. сокетов? Значение подозрительно похоже на максимальное для двухбайтового значения.
Взяли и написали патч для ядра. Или даже не патч, а просто изменили параметр, это же FreeBSD, а не линукс.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте.
S>Вот тут человек не может понять как это возможно на одном сервере -- https://youtu.be/vQ5o4wPvUXg
S>Понятно, что это erlang+elixir. Но все же при физическом ограничении в ~60т. сокетов как это возможно? S>Т.е. я понимаю про non-blocking IO, c10k и т.д., но с10М как? Как возможно наплодить такое кол-во сокетов на одной машине?
BEAM реально творит чудеса в вопросах разработки сетевых приложений.
Здравствуйте, Sharov, Вы писали:
S>Вот тут человек не может понять как это возможно на одном сервере -- https://youtu.be/vQ5o4wPvUXg
S>Понятно, что это erlang+elixir. Но все же при физическом ограничении в ~60т. сокетов как это возможно?
Такого ограничения нет и никогда не было.
Если вы про TCP, все сокеты установленных соединений, созданных коннектом к серверу, имеют один и тот же номер порта с серверной стороны. Ядро их различает по комбинации всех 4 параметров — 2 адреса хоста и 2 порта двух сторон.
Для IPv4 таким образом предел это около 2^79 таких сокетов
Erlang по части держания коннектов и производительности ничуть не лучше, а почти всегда хуже, компилируемых аналогов (разве что они сделали свой JIT). Единственное чем он тут способен побить — это встроенной системой автообновления без рестарта.
S>Т.е. я понимаю про non-blocking IO, c10k и т.д., но с10М как? Как возможно наплодить такое кол-во сокетов на одной машине?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Sharov, Вы писали:
S>>Вот тут человек не может понять как это возможно на одном сервере -- https://youtu.be/vQ5o4wPvUXg
S>>Понятно, что это erlang+elixir. Но все же при физическом ограничении в ~60т. сокетов как это возможно?
N>Такого ограничения нет и никогда не было. N>Если вы про TCP, все сокеты установленных соединений, созданных коннектом к серверу, имеют один и тот же номер порта с серверной стороны. Ядро их различает по комбинации всех 4 параметров — 2 адреса хоста и 2 порта двух сторон.8
N>Для IPv4 таким образом предел это около 2^79 таких сокетов
Гугл выдал:
Maximum number of sockets. For most socket interfaces, the maximum number of sockets allowed per each connection between an application and the TCP/IP sockets interface is 65535.
N>Erlang по части держания коннектов и производительности ничуть не лучше, а почти всегда хуже, компилируемых аналогов (разве что они сделали свой JIT). Единственное чем он тут способен побить — это встроенной системой автообновления без рестарта.
Подождем Skydance'а. Он как раз performance engineer в wa.
Здравствуйте, Sharov, Вы писали:
S>Понятно, что это erlang+elixir. Но все же при физическом ограничении в ~60т. сокетов как это возможно? S>Т.е. я понимаю про non-blocking IO, c10k и т.д., но с10М как? Как возможно наплодить такое кол-во сокетов на одной машине?
Я без особых проблем держал на Си ~300K сокетов, и держал бы и больше, если бы больше ко мне приходило
Никакого ограничения в 60К сокетов нет. Есть ограничение в 60K портов. Но TCP-соединение идеинтифицируется сочетанием адресов/портов на обеих сторонах, так что если у тебя внешние адреса разные, то внутренний порт может быть хоть один на всех.
Кстати, я количество внутренних портов принудительно ограничивал. Иначе оно имеет тенденцию занимать их все, и другим программам начинает не хватать.
Здравствуйте, Pzz, Вы писали:
Pzz>Я без особых проблем держал на Си ~300K сокетов, и держал бы и больше, если бы больше ко мне приходило
Pzz>Никакого ограничения в 60К сокетов нет. Есть ограничение в 60K портов. Но TCP-соединение идеинтифицируется сочетанием адресов/портов на обеих сторонах, так что если у тебя внешние адреса разные, то внутренний порт может быть хоть один на всех.
Вы это мне уже объясняли, было дело. Математика с ув. netch80 не бьется -- под внешней парой понимается адрес:порт? Тогда всего (грубо) 2^32 адресов на 2^16 портов (это все клиент) и на 2^16 портов на сервере, т.е. всего 2^64 возможных соединений. Откуда 2^79?
Здравствуйте, Pzz, Вы писали:
Pzz>Никакого ограничения в 60К сокетов нет. Есть ограничение в 60K портов. Но TCP-соединение идеинтифицируется сочетанием адресов/портов на обеих сторонах, так что если у тебя внешние адреса разные, то внутренний порт может быть хоть один на всех.
Имеется ввиду максимальное количество дескрипторов сокета который вроде как int от 0 до max_int которое можно открыть и их ~60к.
Здравствуйте, Sharov, Вы писали:
S>Вы это мне уже объясняли, было дело. Математика с ув. netch80 не бьется -- под внешней парой понимается адрес:порт? Тогда всего (грубо) 2^32 адресов на 2^16 портов (это все клиент) и на 2^16 портов на сервере, т.е. всего 2^64 возможных соединений. Откуда 2^79?
netch80 говорит, что внутренняя пара так же учитывается. Ты же из внутренней пары считаешь только номера портов, полагая что у сервера только один сетевой интерфейс, но ничего не мешает иметь больше одного.
Здравствуйте, Sharov, Вы писали:
S>Вы это мне уже объясняли, было дело. Математика с ув. netch80 не бьется -- под внешней парой понимается адрес:порт? Тогда всего (грубо) 2^32 адресов на 2^16 портов (это все клиент) и на 2^16 портов на сервере, т.е. всего 2^64 возможных соединений. Откуда 2^79?
Ну, видимо Валентин решил, что локальных IP-адресов тоже может быть много.
Здравствуйте, Kernan, Вы писали:
K>Имеется ввиду максимальное количество дескрипторов сокета который вроде как int от 0 до max_int которое можно открыть и их ~60к.
Sharov:
S>Вот тут человек не может понять как это возможно на одном сервере -- https://youtu.be/vQ5o4wPvUXg
S>Понятно, что это erlang+elixir. Но все же при физическом ограничении в ~60т. сокетов как это возможно? S>Т.е. я понимаю про non-blocking IO, c10k и т.д., но с10М как? Как возможно наплодить такое кол-во сокетов на одной машине?
И главное — зачем?
Не смотрел, но осуждаю.
Есть же UDP, RTP, групповые адреса и пр. страшные слова, чтобы не хранить дофига миллионов состояний каждого соединения...
S>Maximum number of sockets. For most socket interfaces, the maximum number of sockets allowed per each connection between an application and the TCP/IP sockets interface is 65535.
Эээ
ссылку можно?
А то я такой текст нашёл только для z/OS — вы в курсе, что это не Unix, не Windows, не Mac-что-угодно, и вообще настолько далёкая от типовых решений индустрии, что у них всё иначе и называется иначе?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Pzz, Вы писали:
Pzz>>Я без особых проблем держал на Си ~300K сокетов, и держал бы и больше, если бы больше ко мне приходило
S>
Pzz>>Никакого ограничения в 60К сокетов нет. Есть ограничение в 60K портов. Но TCP-соединение идеинтифицируется сочетанием адресов/портов на обеих сторонах, так что если у тебя внешние адреса разные, то внутренний порт может быть хоть один на всех.
S>Вы это мне уже объясняли, было дело. Математика с ув. netch80 не бьется -- под внешней парой понимается адрес:порт? Тогда всего (грубо) 2^32 адресов на 2^16 портов (это все клиент) и на 2^16 портов на сервере, т.е. всего 2^64 возможных соединений. Откуда 2^79?
Я считал, разумеется, и возможность назначить локальной машине сколько угодно адресов.
Исключить 1/8 адресного пространства на всякие мультикасты и класс E и предположить, что сервер сам к себе обычно не ходит...
Здравствуйте, Bill Baklushi, Вы писали:
BB>И главное — зачем?
BB>Не смотрел, но осуждаю. BB>Есть же UDP, RTP, групповые адреса и пр. страшные слова, чтобы не хранить дофига миллионов состояний каждого соединения...
Почему бы не хранить, если мощность сервера позволяет это?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Sharov, Вы писали:
S>>Гугл выдал: S>>
S>>Maximum number of sockets. For most socket interfaces, the maximum number of sockets allowed per each connection between an application and the TCP/IP sockets interface is 65535.
N>Эээ N>ссылку можно? N>А то я такой текст нашёл только для z/OS — вы в курсе, что это не Unix, не Windows, не Mac-что-угодно, и вообще настолько далёкая от типовых решений индустрии, что у них всё иначе и называется иначе? N>)
да-да, я вбил "maximum number of sockets" в гугол и он мне, в рамочке, выдал это определение. Но вообще, я это помню из книжек\вуза, что есть некое ограничение на сокет в виде 2^16. Я это ограничение запомнил на кол-во сокетов в системе (ОС).
N>>Erlang по части держания коннектов и производительности ничуть не лучше, а почти всегда хуже, компилируемых аналогов (разве что они сделали свой JIT). Единственное чем он тут способен побить — это встроенной системой автообновления без рестарта.
S>Подождем Skydance'а. Он как раз performance engineer в wa.
По совместительству еще и один из директоров Erlang Ecosystem Foundation. Занятно, что в данный момент я как раз исправляю часть, которая связана с поддержкой сетевых соединений.
Что именно интересует? Просто открыть 3 млн соединений проблем нет почти на любой языке.
Преимущество Эрланга (и вообще BEAM languages) в том, что:
1. Сделать такое можно буквально в десяток строк кода — сам язык хорошо заточен под подобное использование.
2. Программисту гораздо сложнее выстрелить себе в ногу. Но, конечено, чем более сеньором себя программист считает, тем чаще стреляет даже в Эрланге — от умного дурака защититься сложнее, чем от глупого.
JIT для BEAM пока существует только в экспериментальном проекте, хорошо если через год будет продакшн. Hot code load — да, ценная и важная фича, но не единственное, что важно.
А вот что важно, так это фреймворк, который заставляет программиста думать асинхронно. Все то самое "reactive programming", только очень-очень взрослое по сравнению со смешными поделками, которые сейчас массово вылезают в виде разных react.js и прочего. Все-таки, за 30 лет Эрланг и BEAM повзрослели. Там уже заложены все те концепции, до которых сейчас только думают дорасти очередные итерации "серебряных пуль". Начиная от supervision, и заканчивая immutable releases.
Лучше всего про Эрланг сказал один из его авторов, Роберт Вирдинг:
Virding's First Rule of Programming
After reading the blogs about how good Erlang's concurrency model is and how we just just made a super implementation of it in XXX I have been led to formulate Virding's First Rule of Programming:
Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
KP>BEAM реально творит чудеса в вопросах разработки сетевых приложений.
никаких чудес, просто грамотное использование kqueue/epoll. Но да, читать этот код ох непросто, и вот сейчас как раз epoll-related баг выносит мне мозг капитально.
Т.е. это ты не для себя спрашиваешь, а для друга. Ясно-понятно.
Ну, про количество IP:port с одной и другой стороны тебе уже рассказали (у пользователей могут быть разные IP и у сервера тоже много IP на одном интерфейсе, с портами аналогично), про int вместимостью в 31 бит тоже.
Однако, про IPv6 чё-та совсем и не упомянули, а там каждому клиенту полагается сеть /64 (в стандарте так написано, но правда, даже хостеры стандарты не читают и умудряются на клиента выдавать IPv6 адреса в штуках, откусывая их от своей сети /48 или сколько там дают провайдеру по умолчанию). Впрочем, с таким провайдером я бы не пытался держать 10M сокетов на одной машине.
Также от себя добавлю, что для таких масштабов вполне могут использовать какой-нибудь DPDK, где между приложением и сетевушкой никакого ядра и нет вовсе (драйвер сетевухи со всем сетевым стеком находится прямо в userspace). Там и трафик (количество пакетов) можно сделать больше, и количество соединений держи сколько в память влезет.
Еще полезно отключить, все что мешается — огнестенку, например, с conntrack, да и просто фильтр там будет тормозить. Впрочем, с DPDK, это, наверняка, не актуально, а если сокеты держит ядро, то файрвол, однозначно, будет мешать, даже без conntrack. Фильтровать придется через eBPF (каждый школьник уже может осилить).
Здравствуйте, Sharov, Вы писали:
S>да-да, я вбил "maximum number of sockets" в гугол и он мне, в рамочке, выдал это определение. Но вообще, я это помню из книжек\вуза, что есть некое ограничение на сокет в виде 2^16. Я это ограничение запомнил на кол-во сокетов в системе (ОС).
У меня было точно такое же интуитивное понятие на ограничение числа коннектов на порты. Не знаю даже откуда... А потом столкнулся поближе с темой (нет нет, кучи коннектов не нужно было, наверное скорее делал poor-man in-process "файерволл", что бы это ни было), и пришло озарение, что это не так. А потом даже смешно немного стало, ведь если присмотреться что творится со списком коннектов, то можно когда и никогда разглядеть несогласовааность этой интуитивной теории с реальным миром.
