LINUX.ORG.RU
ФорумTalks

[вещества] повесить HTTP + XMPP на один порт

 


0

0

Я уже писал про отказ от устаревшего http и переход на xmpp вместе с созданием новых интернетов.

Поскольку сразу отказаться от http невозможно, возникает вопрос: как бы на один порт повесить сразу и http-сервер, и xmpp-сервер? Дело в том, что некоторые порты могут быть закрыты, а значит до 5222 порта потенциальный клиент может не достучаться. Правда непонятно еще, как быть с прокси-серверами на пути.

Пока примерно такая идея: через xinetd запускается скрипт, который читает первые 4 байта из сокета (благо, в обоих протоколах нету приветствия и сразу идет запрос от клиента), и если это "GET " или "POST", то запрос редиректится на порт веб-сервера, а иначе на порт xmpp-сервера. Но это слишком кривое решение, грозящее большими лагами (проверено на VNC), может есть что-то получше?

а если запрос сразу на два сервера пересылать, на HTTP и XMPP? Ответ возвращать от того сервера, который ошибку не выдаст

Вообще,XMPP отстой. Как и HTTP. Да и все текстовые протоколы, ввиду своей избыточности :)

Harald ★★★★★
()
Ответ на: комментарий от Harald

> Вообще,XMPP отстой. Как и HTTP. Да и все текстовые протоколы, ввиду своей избыточности

Полностью согласен. Я попробую сделать преобразование xml2tlv для xmpp, чем полностью искореню текст из транспортного уровня. Для разметки текста планирую использовать что-то вроде OBML вместо богопротивного HTML.

EmStudio
() автор топика
Ответ на: комментарий от KRoN73

> lighttpd + magnet?

Что-то не вкуривается, попробую погуглить на эту тему еще

EmStudio
() автор топика
Ответ на: комментарий от Harald

> Да и все текстовые протоколы, ввиду своей избыточности :)

У текстовых протоколов есть один гигантский плюс: в них легко добавлять новые возможности без потери обратной совместимости. И нет проблем с порядком байт, размерами числовых полей и прочими платформенно-специфичными граблями.

Deleted
()
Ответ на: комментарий от Harald

>Вообще,XMPP отстой. Как и HTTP. Да и все текстовые протоколы
smtp, http и dns уж сколько лет живут, текстовый протокол если возможно, то нужно использовать всегда, читай искусство программирования для unix

dimon555 ★★★★★
()
Ответ на: комментарий от Deleted

>И нет проблем с порядком байт, размерами числовых полей и прочими платформенно-специфичными граблями.
их ещё легко тестировать, да хоть telnetом

dimon555 ★★★★★
()
Ответ на: комментарий от ptah_alexs

> Есть документация, сайт проекта, версии ПО для тестирования?

ПО нет, документации нет, сайта пока тоже нет.

Надо сначала все обдумать, а только потом делать.

EmStudio
() автор топика
Ответ на: комментарий от Deleted

> У текстовых протоколов есть один гигантский плюс: в них легко добавлять новые возможности без потери обратной совместимости.

Ой, в XML значит легко добавлять? А то, что существуют преобразователи xml-tlv, которые xml представляют в бинарном виде - это ничего? На выходе имеем бинарный поток, который легко парсится и может быть расширен новыми типами в любое время, при этом даже не нужно клиентов обновлять, которые о расширениях не знают

> И нет проблем с порядком байт, размерами числовых полей и прочими платформенно-специфичными граблями.

Если заранее описать все структуры - никаких проблем не будет.

EmStudio
() автор топика
Ответ на: комментарий от EmStudio

>Если заранее описать все структуры - никаких проблем не будет.

Ключевое слово ВСЕ. Ты Господь Бог?

vada ★★★★★
()
Ответ на: комментарий от deadman

> очередной велосипедостроитель

Интернеты. 2009 год. На веб-страницах расположены десятки счетчиков, голосований, комментариев, в фоне исполняются десятки ajax-запросов, пытающихся актуализировать страницу, а в конце концов пользователь натирает F5 в ожидании новых сообщений, комментариев или изменений текста. Принцип "запросил текст - получил - отключился" стал крайне неэффективным.

Задача: предложить невелосипедный и одновременно некостыльный способ отображения страниц.

EmStudio
() автор топика
Ответ на: комментарий от EmStudio

> Ой, в XML значит легко добавлять?

По сравнению с подавляющим большинством чисто бинарных форматов - да, очень легко.

> А то, что существуют преобразователи xml-tlv, которые xml представляют в бинарном виде - это ничего? На выходе имеем бинарный поток, который легко парсится и может быть расширен новыми типами в любое время, при этом даже не нужно клиентов обновлять, которые о расширениях не знают


Как это противоречит тому, что сказал я?

А ещё есть EBML...

Deleted
()
Ответ на: комментарий от EmStudio

> signed int

> unsigned int


> signed short


> unsigned short


> signed char


> unsigned char


> И кто я после этого?


Человек, который никогда не сталкивался с кроссплатформенным программированием.

Deleted
()
Ответ на: комментарий от Deleted

> Человек, который никогда не сталкивался с кроссплатформенным программированием.

Хорошо, пусть будет: uint32le, sint32le, uint16le, sint16le, uint8le, sint8le. Пойдет? А целевая платформа пусть сама байты переставляет если ей надо.

EmStudio
() автор топика
Ответ на: комментарий от EmStudio

> Хорошо, пусть будет: uint32le, sint32le, uint16le, sint16le, uint8le, sint8le. Пойдет? А целевая платформа пусть сама байты переставляет если ей надо.

Уже лучше. А что предлагаешь делать с float'ами =)?

Deleted
()
Ответ на: комментарий от Deleted

Человек явно не в курсе всех проблем

Да, расскажите ему о сжатии. Тогда потрети практически приравниваются нулю

> А то, что существуют преобразователи xml-tlv, которые xml представляют в бинарном виде - это ничего?

Фу ты, нафиг нафиг. Хотя я думаю там справится

Я думаю что непонятные ему поля он оставляет в тктсово виде

Но все равно нафик нафик

> Принцип "запросил текст - получил - отключился" стал крайне неэффективным.

Вот уж нет. Держат alive соединение постояно еще хуже. А вообще это проблема писателя аякса. Хотя нотификацию от сервера можно тоже придумать. Но ндо понимать, что alive соеди нение для сереров достаочно дорогое

> предложить невелосипедный и одновременно некостыльный способ отображения страниц.

Современный метод более чем хорош. Надо только сжимать страничку

namezys ★★★★
()
Ответ на: комментарий от Deleted

> Уже лучше. А что предлагаешь делать с float'ами =)?

Ты еще все типы перечистить предложи. И изобрести свои строки

EmStudio
() автор топика
Ответ на: комментарий от ptah_alexs

> В любом случае текст универсальнее, можно граби^W сжимать gzip'ом. Sip тому подтверждение.

Зато парсить бинарник проще, опера тому подтверждение, которая на своем OBML экономит до 90% трафика без всякого сжатия! А уж со сжатием еще лучших результатов можно достигнуть, сжатие никто не отменял.

EmStudio
() автор топика
Ответ на: комментарий от namezys

> Вот уж нет. Держат alive соединение постояно еще хуже. А вообще это проблема писателя аякса. Хотя нотификацию от сервера можно тоже придумать.

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

> Но ндо понимать, что alive соеди нение для сереров достаочно дорогое

А что дороже - держать коннект постоянно, или раз в 20 секунд долбиться новым коннектом? Реже не смысла, ибо у пользователя сдадут нервы и он нажмет F5, а это будет еще дороже

EmStudio
() автор топика
Ответ на: комментарий от EmStudio

Мне кажется в данном случае лучше усложнить парсинг но обеспечить расширяемость, ибо хз какие плюшки додумаются прикрутить. Т.е. всё предусмотреть нереально, так лучше сразу предусмотреть возможность расширения протокола.

ptah_alexs ★★★★★
()
Ответ на: комментарий от EmStudio

> Зато парсить бинарник проще

Вот если бы ты реально хоть раз пробовал парсить какой-нибудь бинарный протокол, то знал бы, что это сложнее текста и что там дофига граблей.

> опера тому подтверждение


Опера лишь подтверждает что такое возможно. А ещё есть OSCAR/ICQ. Там тоже бинарный расширяемый протокол. В котором чёрт ногу сломит =).

> которая на своем OBML экономит до 90% трафика без всякого сжатия!


А что это по твоему, если не сжатие?

Deleted
()

И если тебе уж очень сильно хочется бинарный протокол типа XML, то возьми что-нибудь готовое и более-менее "стандартное". Я уже упоминал EBML - http://ebml.sourceforge.net/.

Deleted
()
Ответ на: комментарий от EmStudio

Я вот тут тоже както думал по поводу костыльности http.
Вы предлагаете держать открытое соединение?
Для часто обновляемой информации это подходит, а для редко?

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

ls-h ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.