Здравствуйте, TailWind, Вы писали:
TW>Есть два клиента без внешнего IP TW>Есть сервер с внешним IP
TW>Клиенты хотят оставлять друг-другу сообщения на сервере, обращаясь по http TW>Значит на сервере точно есть php
Как из первого следует второе?
TW>Можно обойтись только php? TW>Или придётся в mysql сообщения складывать?
Можно держать в памяти
TW>MySQL не хочется, потому что он же на диск все сообщения будет складывать. Мне не нравится эта нагрузка на диск
TW>Какие-то ещё есть интересные варианты?
https://redis.io/download/ — Key-Value in memory database. Очень шустрая. Но иногда сбрасывает данные на диск.
TW>Извините за глупый вопрос )
Здравствуйте, TailWind, Вы писали:
TW>Есть два клиента без внешнего IP TW>Есть сервер с внешним IP
TW>Какие-то ещё есть интересные варианты?
email
самый простой и надежный способ.
Здравствуйте, TailWind, Вы писали:
TW>>>Какие-то ещё есть интересные варианты? vaa>>email vaa>>самый простой и надежный способ.
TW>Надо быстро, 25 сообщений в секунду, размер каждого 1-400кБ
в пхп не мастер, но думаю шаред-мемори или вебсокет решение вашей задачи без базы данных.
хотя я бы использовал базу, т.к. это более естественное решение.
Здравствуйте, TailWind, Вы писали:
TW>Клиенты хотят оставлять друг-другу сообщения на сервере, обращаясь по http
Вопросов стало больше. Оставляют до востребования или надо известить второго участника о сообщениях? Надо ли перманентно хранить сообщения на сервере? Должен быть только http?
TW>MySQL не хочется, потому что он же на диск все сообщения будет складывать. Мне не нравится эта нагрузка на диск
Ну а где ты это хранить будешь? Какой размер сообщений? Можно использовать монгу, кэш какой-нибудь или кафку с котторрой забирать сообщение в базу будет скрипт. Пойми, всё и всегда будет, в итоге, храниться на диске.
TW>Какие-то ещё есть интересные варианты?
Я бы написал что-то на go или питоне если его знаешь. Вариант с email тоже неплох.
K>Оставляют до востребования
Да, после прочтения, сообщения удаляются
K>или надо известить второго участника о сообщениях?
А как ты его известишь? У него нет внешнего IP
K>Надо ли перманентно хранить сообщения на сервере?
Нет
Надо сделать так, чтобы они в памяти как-то хранились
K>Должен быть только http?
Да. Только он пробивает всякие корпоративные firewall'ы
K>Ну а где ты это хранить будешь?
В памяти
Я вот и спрашиваю. Какие есть для этого инструменты из стандартного набора доступного на shared hosting (php, mysql)
K>Какой размер сообщений?
1-400КБ
С вероятностью чаще слать 1-10КБ
Частота отправки 25 раз в секунду
K>Пойми, всё и всегда будет, в итоге, храниться на диске.
Тогда почему не MySQL?
У него вроде есть какой-то memory database
Здравствуйте, TailWind, Вы писали:
TW>А как ты его известишь? У него нет внешнего IP
Ну как-как, через сервер. Клиент открывает вёбсокет и ждёт входящих/посылает исходящие. Просто не рви сессию и всё. Вроде так. TW>Надо сделать так, чтобы они в памяти как-то хранились
МонгоДБ разве что. TW>Да. Только он пробивает всякие корпоративные firewall'ы
Не пробивает, а порты обычно открыты. Вряд ли DPI у компаний стоит поэтому можно просто попробовать через HTTP порты наружу залезать с любым трафиком. Конечно, если там не корп. решение которые именно проксирует HTTP, а не просто дырка в под http. TW>В памяти TW>Я вот и спрашиваю. Какие есть для этого инструменты из стандартного набора доступного на shared hosting (php, mysql)
Откажись от шареда и возьми VPS. TW>1-400КБ TW>С вероятностью чаще слать 1-10КБ TW>Частота отправки 25 раз в секунду
Посчитай сколько за час наберётся. TTL у сообщений есть или они будут жить пока не заберут? TW>Тогда почему не MySQL? TW>У него вроде есть какой-то memory database
Ну раз есть, то в чём вопрос?
K>Посчитай сколько за час наберётся. TTL у сообщений есть или они будут жить пока не заберут?
Объём не проблема
Если второй клиент не забирает, можно поставить порог
Например, 20 сообщений, дальше возвращаем ошибку при попытке добавить 21-ое
Первый клиент получив такой ответ немного ждёт и перепосылает
Если опять переполнение, отключается
K>Ну раз есть, то в чём вопрос?
Послушать умных людей с опытом
Я сам тоже умный, но без опыта в этой теме
Увижу хорошую идею сам дальше во всём разберусь
Почему тема называется "тунелирование"
У меня сейчас всё замечательно работает для случая когда у одного из клиентов есть внешний IP
Думаю как соединить двух клиентов без внешних IP
Значит нужен какой-то посредник
Так вот он должен быть максимально простым и не дорогим
Здравствуйте, TailWind, Вы писали:
TW>Думаю как соединить двух клиентов без внешних IP TW>Значит нужен какой-то посредник TW>Так вот он должен быть максимально простым и не дорогим
Здравствуйте, TailWind, Вы писали:
TW>Объём не проблема
Ну да, не проблема, после чего ты начинаешь рассуждать про TTL в 1 секунду для пакета. TW>Если второй клиент не забирает, можно поставить порог TW>Например, 20 сообщений, дальше возвращаем ошибку при попытке добавить 21-ое
У тебя 25 сообщений в секунду. TW>Первый клиент получив такой ответ немного ждёт и перепосылает
Это гемор. Если поток данных плотный, то лучше слать репорты с статистикой по которой уже и решать что делать дальше. TW>Если опять переполнение, отключается
Ты бы лучше рассказал что за данные у тебя. TW>Думаю как соединить двух клиентов без внешних IP TW>Значит нужен какой-то посредник TW>Так вот он должен быть максимально простым и не дорогим
Мне вообще кажется что проще будет VPN поднять и объединить этих двух клиентов в одну сетку где они друг друга видят.
Я тут почитал в соседней ветке про STUN
Пишут что это трюк
Работает с вероятностью 95%
Не, мне не нужен трюк
Мне нужен какой-то стандартный метод
Который можно сделать из подручных средств, которые и так есть под рукой
Пусть даже это и не будет оптимально по скорости
Подручные средства:
— shared hosting компании
— NAS компании со встроенным web сервером, на который можно редиректить внешний IP
Здравствуйте, TailWind, Вы писали:
TW>Думаю как соединить двух клиентов без внешних IP TW>Значит нужен какой-то посредник TW>Так вот он должен быть максимально простым и не дорогим
Здравствуйте, TailWind, Вы писали: TW>Какие-то ещё есть интересные варианты?
Выглядит как типичнейший кейс для message queue. Учитывая ваши запросы по размеру сообщений, предлагаю Apache Kafka.
Дополнительно:
— если умножить средний размер сообщения на кол-во сообщений в секунду, какой трафик получится?
— а если после gzip?
— допустима ли потеря сообщений (перезапуск сервера например)
— может ли клиент отправлять сообщения, не дожидаясь их получения другим клиентом? Сколько таких сообщений он может отправить?
— сколько планируется отправителей и получателей? Они связаны попарно или, допустим, 100 отправителей и один получатель?
— соответственно, какой пиковый трафик до получателя получается?
— интернет или интранет? являются ли отправители и получатели доверенными сервисами?
scf>- если умножить средний размер сообщения на кол-во сообщений в секунду, какой трафик получится?
Зависит от того что на экране происходит
Обычно ~60kB/s
scf>- а если после gzip?
Уже всё сжато
scf>- допустима ли потеря сообщений (перезапуск сервера например)
Нет. Обязательная доставка всех сообщений
Обрыв связи допустим. Как следствие перезапуск соединения
scf>- может ли клиент отправлять сообщения, не дожидаясь их получения другим клиентом? Сколько таких сообщений он может отправить?
Сделаем FIFO на промежуточном звене. Пока не забьётся будет принимать
scf>- сколько планируется отправителей и получателей? Они связаны попарно или, допустим, 100 отправителей и один получатель?
Обычная ситуация: 1 отправитель и 1 получатель
Остальные ждут пока их пригласят
Получатель выбирает кого пригласить
scf>- соответственно, какой пиковый трафик до получателя получается?
Обычно ~60kB/s, если мышкой водить по экрану
Если кино смотреть, то конечно больше. Но тогда и FPS автоматически снижается
scf>- интернет или интранет?
Интернет
Самая сложность это не Москва-Москва. А Москва-США. Так как сообщение дольше идёт
scf>являются ли отправители и получатели доверенными сервисами?
Не знаю, что это значит
