Pull to refresh
41
0
Anton Batenev @antonbatenev

Снимаю. Порчу.

Send message

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

Тут стоит обратить внимание, что порядок сортировки будет определяться текущей локалью:

$ LC_ALL=C ls -1
TEST.txt
test.txt
$ LC_ALL=ru_RU.UTF-8 ls -1
test.txt
TEST.txt

и конструкции вида ls -1 | head -n 1 - поле для сбора урожая.

На входе все та же четверка { client_ip, client_port, server_ip, server_port }. Пара { server_ip, server_port } не меняется (на ней listen socket), но { client_ip, client_port } в обычном мире всегда разный.

Есть краевой случай, когда клиент откроет 65K соединений из одного и того же места (src_ip) и действительно получит ограничение. Но это ограничение будет для исходящих соединений клиента, а не для входящих сервера — сервер продолжит обслуживать эти 65К соединений клиента (которые он все же смог открыть) плюс все соединения других клиентов.

Если же подобному клиенту нужно более 65К соединений (я не представляю зачем, но допустим), то ему нужно будет использовать разные src_ip (но кажется это уже проблемы клиента, а не наши).
А с входящим трафиком обычно никаких проблем в контексте количества сокетов нет — он же с различных клиентских адресов идет. Так что тут лишь бы CPU хватило на терминацию TLS соединений, а количество соединений уже особого значения не имеет. Когда кончится CPU переходим к L3 балансировке трафика на разные физические машинки, где схема выше повторяется.
Нет. Как-то так:

image

a) nginx может указывать в качестве src_ip требуемые адреса. Естественно их нужно поднять перед этим на интерфейсе. Если nginx и backend в одной сети, то поднимаем на lo нужное количество адресов из 127.0.0.0/8.
b) backend может слушать как на разных портах, так и на разных ip. Так же как с nginx их нужно поднять на интерфейсе.

Используя все вместе (или по отдельности из того, что технически возможно) получаем практические неограниченное число возможных комбинаций { src_ip, src_port, dst_ip, dst_port }.
Да. Классический способ обхода — биндинг слушающего бэкенда на 2+ адреса/порта и/или биндинг исходящего трафика reverse proxy на 2+ адреса. Поскольку каждое TCP соединение определяется четверкой {src_ip, src_port, dst_ip, dst_port} получаем почти неограниченные возможности.
Картинки делались в app.diagrams.net (первое попавшееся online приложение для рисования диаграмм)
Этот вывод часто используют для отправки каких-то обобщенных данных в системы мониторинга.
In particular, do not sexualize the term «Julia» or any other aspects of the project. While «Julia» is a female name in many parts of the world, the programming language is not a person and does not have a gender. [1]

И вот ощущение, что они сначала создают себе проблемы, а потом героически их преодолевают не покидает и во время чтения документации.
чей домашний роутер/компьютер не поддерживает ipv6, или поддерживает, но его надо настраивать (время, деньги, проблемы)

Протокол IPv6 датирован 1996 годом — его поддерживают все ОС и подавляющее большинство домашних роутеров (если это не совсем «динозавры»). Приятным бонусом IPv6 является простота настройки и автоконфигурирование — для среднестатистического пользователя переход будет абсолютно незаметным.

Поломается кровавый enterprise и мелкие поделки, где до сих пор используют gethostbyname / sockaddr_in / etc, но для первых есть специально обученные люди, умеющие строгать нужные костыли, а вторым туда и дорога.
IPv6 был придуман, чтобы отказаться от NAT, а в итоге приходится городить NAT64 для выхода в IPv4 сети :(
А для чего вы используете информацию о котировках в программе учета личных финансов? Зачем могут вообще понадобиться котировки понятно, интересно применение именно в контексте данного типа ПО.
Верно, но в той реализации libtoxcore, о которой идет речь, для вычисления расстояния (индекса ключа) используется только половина длины ключа, что и приводит к тому, что для половины пространства ключей индекс будет больше 127. Хотя из написанного это сразу неочевидно, согласен.
А когда у вас появится IPv6? А то 5G — это модно и современно, а используете протоколы прошлого века.
#133160
2016-05-26 07:19:04, «Ваш запрос перенаправлен в ответственный отдел технической поддержки.»
2016-07-13 12:26:29 (чуть-чуть не дотянули до 2-х месяцев между ответами), «Пароль на ssh root?»
Для работы с Яндекс.Диск можно попробовать использовать «легковесный» ydcmd.
Работает, народу прибывает (хотя сейчас наблюдается «сезонный спад»), РФ на первом месте по суточному количеству нод, появились русскоязычные чаты (бот Kalina), зарождается эра ботоводства (пока в зачаточной стадии, но попытки растут как грибы), народ с нетерпением ждет вливания кода групповых чатов в ядро.
Порт в роутере пробрасывать не требуется — Tox сам "пробивает" NAT.
Изменения в API известны задолго до их вливания в ядро. Так, например, к новому ToxAV были готовы все клиенты и переключились в течении суток. Я бы не назвал это "ломают".
Проблема с мобильными клиентами, как мне кажется, немного в другом — людям, которым интересен проект, не особо интересна мобильная версия. Людям, которым интересна мобильная версия, не особо интересен проект. И тех и других по своему можно понять.
"Хранитель" и будет этим центральным сервером. Сейчас ничего не мешает взять консольный клиент и запустить его на своем выделенном сервере — клиент будет 24х7 в онлайне, а уж чем забирать с него историю и как через него отправлять сообщения — это вопрос не сильно сложный технологически.
577 Россия vs 538 США — Achievement Unlocked!!! :)

Information

Rating
Does not participate
Registered
Activity