Size: a a a

2021 November 30

IK

Igor Karymov in ErlangRus
В целом да, но получается, что тут сам сервер выполняет роль stun. Т.е предполагается что первая датаграма которая от клиента приша привела к резервированию порта на нате. По крайней мере в протоколе должно быть что-то типа keep alive чтобы держать его открытым (т.е аналог stun пингов).
источник

MP

Maxim Pushkar in ErlangRus
Коллеги, я постил вакансию бэкенд-разработчика на Эрланге несколько дней назад, никого не заинтересовал?
источник

LL

Lama Lover in ErlangRus
Не, там всё хитрее. QUIC даёт уникальные идентификаторы каждому клиенту, поэтому клиент может подключаться с другого IP и с другого порта, и продолжать старое соединение. При этом можно работать сразу через несколько интерфейсов, и всё такое
источник

IK

Igor Karymov in ErlangRus
Не очень понятно как то работает. Точнее кажется, что это не совсем то, что я имею ввиду.
источник

IK

Igor Karymov in ErlangRus
Ну т.е ок ты можешь сразу с нескольких портов ходить мейнтейня одно логическое соединение. Но сервер то должен как-то иметь возможность тебе датаграмму послать так чтобы она дошла
источник

LL

Lama Lover in ErlangRus
Я это к тому что нет никакой необходимости держать UDP соединение и пинговат. Если роутер забудет UDP соединение, то новое UDP соединение всё равно продолжит старое QUIC-соединение
источник

IK

Igor Karymov in ErlangRus
Для этого он будет слать её на адрес ната с каким то портом. И порт должен оставаться связан с этим конкретным клиентом за натом.
источник

IK

Igor Karymov in ErlangRus
я послал запрос. Сервер его процессит минут 5, потом когда всё готово пробует отправить ответ. А порт с которого пришёл запрос уже закрыт.
источник

IK

Igor Karymov in ErlangRus
в итоге ответ послать не получится. Сервер со своей стороны открытие нового никак не сможет инициировать.
источник

IK

Igor Karymov in ErlangRus
так что пинги нужны
источник

IK

Igor Karymov in ErlangRus
Если они на апликейшн левеле, то это в принципе хорошая идея. Так как даже для tcp их всё равно надо делать для долгоживущих соединений, несмотря на то, что вроде как и есть TCP keep alive.
источник

LL

Lama Lover in ErlangRus
Да, точно, у меня утро вторника, я туплю
источник

DF

Dmitry Frolov in ErlangRus
udp соединение - звучит дико)
источник

DF

Dmitry Frolov in ErlangRus
нет в udp соединений
источник

LL

Lama Lover in ErlangRus
Ну а как ещё описать этот стейт, который держит роутер
источник

LL

Lama Lover in ErlangRus
> Ну а как ещё описать этот стейт, который держит роутер
источник
2021 December 02

SB

S B in ErlangRus
Я опять со спорным вопросом.
Если у меня нет требований к производительности и я хочу обработку ХТТП запросов построить на try/catch, чтобы из любой точки можно было быстро замкнуть… и у меня cowboy. Как лучше всего это сделать? Могу ли я например кастомное поведение использовать?
источник

SB

S B in ErlangRus
throw(204) -> 204, No Content
источник

SB

S B in ErlangRus
По такому принципу.
источник

SP

Sergey Prokhorov in ErlangRus
Если тело запроса предварительно загрузить в память, то должно сработать
источник