в либе вот куски кода https://github.com/RevenantX/LiteNetLib/blob/master/LiteNetLib/NatPunchModule.cs и пример https://github.com/RevenantX/LiteNetLib/blob/master/LibSample/HolePunchServerTest.cs

В смысле сервер может пропустить, а у клиента с другого айпишника ничего не получится? Тогда по идее можно делать эту проверку с другого айпишника?

я аж запутался

я просто слегка накурен)

Идея была запилить инструмент, прозрачно соединяющий двух (для начала) клиентов между собой любым доступным способом (вплоть до связи через серверы мессенджеров, а то и вовсе через почту с буферизацией пакетов и пересылкой их пачками в письмах). Чтобы в приложении можно было ни о чём кроме некоего идентификатора не думать. В детстве на вижуал бейсике пытался какие-то игрушки, чаты делать, да всё только по локалке выходило. Разве что получилось "ssh" через мейлру агент сколхозить ? А теперь думаю чего бы не запилить либу (скорее даже утилиту). И ещё одну для какой-нибудь маршрутизации поверх этого. А поверх уже любые хотелки. Что-то вроде "запили для себя, друзей, коллег и ботнета примитивную оверлейную сеть с чем вздумается на прикладном уровне" (речь не про tor, i2p и т.п. а про легковесную ерунду для наколенных задач).

норм идея

Можно будет всякие вещи хоть на баше/батниках ваять.

ребят) раз вы тут по сетям спецы, помогите с фаерволом)))))

мягко выражаясь я зае*ался...

дано: ноут, МТС модем и телефон

надо: открыть доступ по желаемому порту с телефона к компу

по сути локальная сеть через модем

это вообще фаервол?

и где он

на ноуте открыл, однозначно

это NAT

не не не, это локальная сеть

тоесть модем раздаёт wi-fi и ноут с телефоном к нему подрублены

по 80 порту идёт

а по 8080 нет

может роутор железно это блокировать без возможности настройки?

# firewall-cmd —get-active-zones FedoraWorkstation interfaces: wlp3s0 # firewall-cmd —zone=FedoraWorkstation —query-port=8080/tcp yes

я вообще то делаю хоть?

причём даже с локальной машины по ip не пропускает localhost:8080 работает 192.168.0.100:8080 не работает

Вот какие-то подобные задачи эта утилита и будет выполнять. Прост чёт типа superPuperNet listen host=our_goodness_chat name=vasya-server channels_only=ip,some_messenger,gmail gmail=example@gmail.com:qwerty transfer_to_local_port=1234

И ждём коннектов на 1234 с localhost'а

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

Хотя надо будет по-нормальному это продумать чтобы не переделывать.

что значит адрес привязки в vibe? settings.bindAddresses = ["::1", "127.0.0.1"];

ну, как я понимаю, не только в vibe

Ну первое походу ipv6.

Для привязки к разным интерфейсам, думаю. Например: есть eth0 с 192.168.5.1 и eth1 с 192.168.1.1. И это позволяет указать, с какого именно будет слушать Могу ошибаться, не уверен

Меня больше интересует что из себя сокет представляет. Это область в памяти? Или как?

это я к тому, что смысл был этом значении брандмауер был не причём

сокет это в памяти)

но как файл на диске

если unix сокет

вроде это тупейший буфер с блокировкой

можно положить туда и можно забрать

вроде ничего больше

А там адрес получателя хранится?

Поток переключился допустим уже и что дальше? Как данные попадут нужному потоку

там не хранится адрес

unix сокет создаётся как файл

ты его открываешь и читаешь или пишешь как в обычный файл

в другом приложении тоже читаешь и пишешь

но это unix сокет

А сетевые сокеты это не юникс сокеты?

Разве юникс сокеты это не юникс сокеты?

Все зависит от уровня владения терминологией ;)

А сетевые сокеты это не юникс сокеты?

Вообще в линуксе по крайней мере есть два понятия - TCP сокеты и UNIX сокеты. Первый сокет - это установленное с интернетом соединение, а второй - это файл в файловой системе, куда тоже можно писать и читать оттуда.

Tcp сокет что в себе хранит? Это область памяти?

Я в деталях не знаю, да и думаю что мало кто знает. Это такая абстракция, чтобы не вникать в подробности реализации.

Ну во-первых область памяти конечно, со всякими данными, ссылками на соединения, таймеры, буфера, что там еще есть..

Думаю реализации могут различаться на разных системах.

Просто как данные в нужный поток попадают?

tcp-сокет это всётаки не "соединение с интернетом", а открытый (на прослушку или соединённый с кем-то) порт

А что такое порт? Участок памяти?

порт это число от 0 до 65536

порт в tcp/ip

номер

айдишник этого дела

Да, это получается адрес сокета в рамках одного хоста

А IP - адрес хоста в сети хостов

Т.е. чтобы отправить данные в опред. поток, тебе надо знать IP + port

ERROR: S client not available

Но с точки зрения программиста - сокет это у тебя переменная куда ты можешь написать что-то и прочитать

Ну и всякие другие операции, перевести в неблокирующий режим и т.д.

и итоге если пакет приходит на 123.45.67.89:666 то на 123.45.67.89 его прочтёт тот, кто специально читает 666 порт

при том оно скорее даже так: local_host:local_port remote_host:remote_port

А как данные в нужный поток попадают? Поток выполнения то может быть уже другим нежели тот который отправил запрос

Какой-то слишком абстрактный вопрос. Какой поток, какие данные?

Ну вот есть поток выполнения. Он отправляет запрос к БД. Потом идет переключение контекста. Но когда данные прилетают там уже другой поток активен.

Если бы один поток = один порт было бы ясно, а тут порт один а потоков много

Может дело в том, кто прочтёт из порта?

Кто прочтёт тот и прочтёт

Тогда поток будет получать чужие данные

С чего-бы? Если он слушает порт, то прочтёт данные их этого порта. Они не могут быть "чужими". Если он коннектится на удалённый порт, то прочтёт данные соответствующие local_host:local_port remote_host:remote_port

Или что значит чужие?

Ну вот у приложения допустим пять потоков. Один поток отправил запрос, потом уснул, потом ОС передала управление на другой поток и второй поток видит данные для первого потока

В этом самом сокете

Ему для этого нужно делать пять сокетов

Я конечно могу ошибаться, так как по сути не работал напрямую с tcp/ip двенадцать лет (со школы ?), и то было в вижуал бейсике, но там это именно так и делал: создавал целый массив tcp-сокетов.

Ну вот у приложения допустим пять потоков. Один поток отправил запрос, потом уснул, потом ОС передала управление на другой поток и второй поток видит данные для первого потока

Ты задаешь опасные провокационные вопросы, не надо работать с одним сокетом из нескольких тредов.

А, кстати, "кто первый встал того и тапки" будут скорее всего

Не обязательно же всем надо чтобы кто отправил тот и получил ответ

Один отправил, далее кто на момент ответа оказался свободен тот и обработал

Чудесно же)

Вроде нельзя двум приложениям на один порт повеситься

Система следит за этим

Речь то не за приложения (процессы), а за потоки

А

Не разглядел

Пару лет назад читал, что nginx как-то так и делает: n потоков-воркеров берут запросы из очереди и обрабатывают, при этом медленный запрос заёмёт один воркер, а за это время другие воркеры обработают кучу быстрых запросов.

Сами эти воркеры очень редко убиваются или создаются новые (их просто некое оптимальное количество), таким образом накладные расходы ещё сокращаются

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

https://habrahabr.ru/post/260669/

Вот, к слову, хорошая статья про неблокирубщие сокеты в Nginx