p2p чаты и невозможность TCP-прокола NAT-а в сетях 4G?

Когда оба клиента за натом арбитр всё равно нужен. Для TCP есть stunt/turn. Много мессенджеров несмотря на свои утверждения гоняют ключи, а то и трафик целиком через свои сервера, а не напрямую.

Скорее всего где то я ошибаюсь, но где?

Скорее всего в том месте где ты веришь многим месенджерам (:

гоняют текст р2р, не подключая сервер. С другой стороны для этого tcp протокол нужен

Не нужен. Текст можно по UDP гонять, а гарантию доставки обеспечивать обыкновенным подтверждением. Послал. Если в течении 5 сек подтверждение не вернулось, послал ещё раз. Если снова не вернулось, то ещё раз. И так до тех пор, пока не придёт подтверждение.

Если подтверждение пришло, то помечать мессагу как отправленную.

P.S. Кстати, если бы ты изучил существующие протоколы, то понял, что подтверждение приходится делать даже при TCP - ибо то что ты отправил мессагу по tcp, не значит, что мессага дойдёт - например, если провод у получателя выпал после того, как ты отправил мессагу, то он её не получит.

P.S. Кстати, если бы ты изучил существующие протоколы, то понял, >что подтверждение приходится делать даже при TCP - ибо то что ты >отправил мессагу по tcp, не значит, что мессага дойдёт - >например, если провод у получателя выпал после того, как ты >отправил мессагу, то он её не получит.

Это все справедливо только для случая когда есть посредник при передаче - он же выступает буфером. Для p2p обрыв связи у адресата вызовет tcp retransmission timeout у отправителя. Сообщение не будет доставлено.

Не нужен. Текст можно по UDP гонять, а гарантию доставки >обеспечивать обыкновенным подтверждением. Послал. Если в течении >5 сек подтверждение не вернулось, послал ещё раз. Если снова не >вернулось, то ещё раз. И так до тех пор, пока не придёт >подтверждение.
Если подтверждение пришло, то помечать мессагу как отправленную.

Это не гарантия доставки, а подтверждение доставки/прочтения на прикладном уровне (галочки в мессенджере). С TCP/UDP ничего общего не имеют и реализуются независимо.

Для p2p обрыв связи у адресата вызовет tcp retransmission timeout у отправителя. Сообщение не будет доставлено.

Ретрансмиссии tcp не управляются в user-level. Вы в конце-концов получите разрыв tcp соединиения, но о том, получил ли последнее сообщение адресат ни у кого, в том числе у «посредников» не будет данных. Всё дело в том, что «чатики» имеют немного специфичное отношение к связи. Если для получения странички www ну или файлика по ftp, серверу совершенно всё равно отвалился ли получатель или нет, то tcp без подтверждений на level-7 идеально подходил. Но вот для чатиков, где собеседник заинтересован, что вы получили его сообщение в полном объёме просто tcp уже не достаточно.

Понял про что речь: при разрыве адресат получил сообщение и занёс в свою базу, а отправитель не может занести в базу отправленных так как нет подтверждения. Две базы стали неконсистентны, нужна процедура согласования на прикладном уровне. Но имхо топикстратер всё таки спрашивал про stunt/turn изначально.

Недавно было на лоре интенсивное обсуждение темы хартбитов в прикладных протоколах поверх tcp.

В кратце - keep alive казалось бы наше всё, но что бы портабельно, эффективно и не завязываясь на транспорт, даже потоковый, нужны они. Особенно в двухсторонних p2p или rpc схемах, когда каждый вызывает каждого.

Это не гарантия доставки, а подтверждение доставки/прочтения на прикладном уровне (галочки в мессенджере). С TCP/UDP ничего общего не имеют и реализуются независимо.

Ничего не «независимо». Это всё одна проблема: помечать сообщение в базе как доставленное и больше не отправлять, или не помечать и пытаться отправить ещё и ещё.

Ты пишешь как мамкин теоретик. А я пишу как практик, который этот механизм уже реализовал в Пандоре.

Ты пишешь как мамкин теоретик. А я пишу как практик, который этот механизм уже реализовал в Пандоре.

Воу-воу, полегче. Я пишу исходя из фундаментальных понятий, в данном случае это стек TCP/IP, которые использую на практике. А вот вас на хабре попрекнули в том что вы не уважаете открытые (т.е. как раз общепринятые) протоколы и отчасти справедливо, а сама Пандора несколько смахивает на «векторный фидонет». Я даже руководство к ней скачал на 67 страницах - я поражён вашим упорством) Но тем не менее где же клиент Пандоры под ios или android? Ведь в контексте вопроса автора сейчас бы провели натурный эксперимент.

P.S. под 18.10 ppa нужно поправить:

mike@asus:~$ sudo apt-add-repository -y ppa:pandora-net/ppa
Игн:14 http://ppa.launchpad.net/pandora-net/ppa/ubuntu cosmic InRelease
Ошб:16 http://ppa.launchpad.net/pandora-net/ppa/ubuntu cosmic Release 
  404  Not Found [IP: 91.189.95.83 80]
E: Репозиторий «http://ppa.launchpad.net/pandora-net/ppa/ubuntu cosmic Release» не содержит файла Release.
N: Обновление из этого репозитория нельзя выполнить безопасным способом, поэтому по умолчанию он отключён.
N: Информацию о создании репозитория и настройке пользователя смотрите в справочной странице apt-secure(8).

Ещё в догонку. Вместо философского guide.ru.odt у вас же есть вменяемый todo.ru.txt, а там прямо секция отведена на решение проблем с NAT:

прострел NATов через: UPnP (IGD?) - for local, NAT-PMP, STUN, SOCKS, NAT-T (in IKE),
  TURN, RSIP, MIDCOM, ICE, Teredo(miredo), SBC, SYN-TCP, UDP-pounching, ALG
  1) дырявление UDP аналогично Skype (встречный перебор портов)
  2) через STUN-сервис: узнаем типы NATов, и разумно долбим
  3) с пробитием через SYN-TCP
  4) TURN?
  5) туннель через открытый узел
  6) взаимное лобовое UDP-пробитие (то же самое что п.1?)
  7) NAT-PMP (в рамках Bonjour)
  8) IGD (в рамках UPnP)
  9) ICM (расширение к STUN+TURN)
  10) NAT-T (IKE)
  11) RSIP (эксперементальный протокол и навесок к NAT)
  12) SOCKS

Я пишу исходя из фундаментальных понятий

Дак я и говорю «теоретик» :)

на хабре попрекнули в том что вы не уважаете открытые (т.е. как раз общепринятые) протоколы

Абсолютно не уважаю, ни форматы, ни протоколы, ни стандарты. Начиная с 2000-го года ИТ пошло не в ту сторону. Всё, что сделано корпорастами за последние 15 лет - это пафосное перераздутое дырявое (специально для зондов) вендер-лочное говнище.

где же клиент Пандоры под ios или android?

А какую полезную роль могут играть пальцетыки в p2p-сети? Особенно в начале, когда нет полноценных узлов?

E: Репозиторий «http://ppa.launchpad.net/pandora-net/ppa/ubuntu cosmic Release» не содержит файла Release

Какой дистрибутив-то хоть? Телепаты в отпуске. Если распоследний, то он не сделан (руки не дошли). Установи через GitHub.

Вместо философского guide.ru.odt у вас же есть вменяемый todo.ru.txt, а там прямо секция отведена на решение проблем с NAT:

Про дырявление NAT постоянно спрашивают. Реализовать перфорацию всеми способами очень трудозатратно - как раз, кстати, потому что это сплошь перераздутые копро-стандарты.

Сейчас в Пандоре, если уж про нее речь зашла, есть и куча других более важных подсистем, которые надо дописывать в 1ю очередь.

Но автор поста уже пробился через NAT, он спросил не про NAT, и не про телефоны - он спросил, можно ли гонять текст через UDP, если часть пакетов теряется. Я и ответил: можно, но с подтверждением от другой стороны.

P.S. В Пандоре, кстати, обмен сообщениями идет через TCP (UDP в планах), но даже в этом случае через подтверждения.

Pjsip - не помощник?

Попробуй Quik.