JRuDevels

Jabber Russian Developers Forum.
Log in Register FAQ Memberlist Search JRuDevels Forum Index

JRuDevels Forum Index » Vacuum » протокол Jingle Goto page Previous  1, 2, 3, 4, 5  Next
Post new topic  Reply to topic View previous topic :: View next topic 
PostPosted: Fri Mar 30, 2012 3:51 pm Reply with quote
fk00
Начинающий тестер
Начинающий тестер
Joined: 27 Mar 2012
Posts: 22




ejabberd умеет XEP-0065, но, насколько я понял (код не смотрел), только для file transfer

SOCKS теоретически умеет проксировать UDP, поэтмоу если это возможно - то прикручивание RTP к SOCKS не должно вызывать больших затруднений. Могу по неграмотности, конечно, ошибаться...

Openfire умеет вообще все... MediaProxy out of the box, Jitsi на раз пробивает все наши не самые простые фаерволы.... хотя его еще надо тестировать и тестировать


Last edited by fk00 on Sat Mar 31, 2012 3:08 pm; edited 3 times in total
View user's profile Send private message
PostPosted: Fri Mar 30, 2012 4:04 pm Reply with quote
fk00
Начинающий тестер
Начинающий тестер
Joined: 27 Mar 2012
Posts: 22




Quote:
Да, но опенсорс здесь проигрывает по возможностям не потому, что его авторы не могут сделать так же хорошо, а потому, что для подобного рода софта нужны некоторые денежные вливания, которых взять негде.


я на это и намекал

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

Quote:
На что спорите?

на интерес Grin

Quote:
Прекрасно, блин, а для домашних пользователей нужен STUN, и что теперь? О чём сей трёп? В корпоративной среде можно вообще без NAT traversal обходиться, чистым UDP-транспортом при нормальной настройке.


Quote:
Принципиальная ошибка в упомянутых "простых" стандартах это смешивание двух концепций - p2p и c2s. Это приводит к двум фундаментальным недостаткам: в корпоративной среде не выполняется принцип разделения информационной среды, а в SOHO секторе - все это просто плохо работает, потому что зоопарк и реализовано далеко не везде.


Quote:
Нет уж вы расскажите, пожалуйста, а то кругом обрывки фраз непонятного назначения и никакой конкретики.


не вопрос!
вам приятно будет писать шейпер для вот такой вот простенькой схемки?

С1 -----NAT------ S1 -----NAT------ S2 -----NAT-----C3
|
NAT
|
C2

Просьба также учесть 3 фактора:
1. Количество очередей с приоритетами порядка 50
2. Количество VLAN порядка 30
3. Файерволов порядка 6-10 в данном конфиге.

А как насчет настройки каждого софтового фаервола? Порт-маппинг? ISP не даст. Это, повторяю, корпоративная среда, где "настроить можно не все", так как хочется....

Я, конечно же, не рисовал Wi-Fi точки (UPnP, угу), stateless firewalls, WAN xDSL и пр. прелести сети, сильно отличающейся от домашней.

Попробуйте обеспечить непрерывность UDP потока в такой среде, не говоря уже о multicast/IGMP, который при ваших айсах тихо умрет, не выйдя из стадии зиготы.
View user's profile Send private message
PostPosted: Fri Mar 30, 2012 4:14 pm Reply with quote
fk00
Начинающий тестер
Начинающий тестер
Joined: 27 Mar 2012
Posts: 22




Quote:
STUN и TURN описаны в транспорте ice-udp, на данный момент это мейнстрим и поддерживать их необходимо.


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

По поводу релей нодов, они пока не являются даже более-менее стабильным форматом, AFAIK. К тому же, они должны использоваться не вместо, а ВМЕСТЕ со STUN, ибо, вдумайтесь, если все сидят за NATом, кто будет нодами?

Стабильным форматом и не станут.... Нигде не реализованы почти - только openfire и jitsi
нодами будут кто угодно, хоть сами клиенты (AFAIK skype так и работает)


я к чему это все веду... стандарты, это, конечно, супер хорошо
но предлагаю как-нить взглянуть на плагин для миранды mirandacomm2, который работает лучше asterisk в плане качества связи, а годов ему с последнего обновления 5 уже
и никаких стандартов вам, просто сделано так, чтобы работало....
хотя, конечно, для корпоратива тоже не годится
View user's profile Send private message
PostPosted: Fri Mar 30, 2012 5:13 pm Reply with quote
Binary
Разработчик
Разработчик
Joined: 17 Dec 2004
Posts: 1712
Location: Омск




fk00 wrote:
Binary wrote:
Yagiza wrote:
По-моему, данная дорожная карта весьма состоятельна. Или Вы имеете какие-то возражения против такой последовательности?


Ага, имею. Использование SOCKS5 транспорта может помешать использовать готовые медиа-фреймворки, а ещё никто нынче не умеет этот транспорт использовать совместно с jingle, как тестировать прикажете?


ejabberd умеет XEP-0065, но, насколько я понял (код не смотрел), только для file transfer

Вы неправильно поняли, ejabberd'у до лампочки, какой именно контент будет передаваться через SOCKS, XEP-65 этого не регламентирует.

Quote:
SOCKS теоретически умеет проксировать UDP, поэтмоу если это возможно - то прикручивание RTP к SOCKS не должно вызывать больших затруднений. Могу по неграмотности, конечно, ошибаться...

Всё верно, только вот XEP-65 нигде, кроме xmpp нет, так что проблемы с взаимодействием обеспечены. (UDP пока никто не умеет)

Quote:
Openfire умеет вообще все... MediaProxy out of the box, Jitsi на раз пробивает все наши не самые простые фаерволы.... хотя его еще надо тестировать и тестировать


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

TURN, по идее, тоже пройдёт любой фаерволл, так что зачем лишняя сущность, пока ума ни приложу.

_________________
And I'm feeling good!
View user's profile Send private message Send Jabber-message Visit poster's website HabaHaba - Fast communicate
PostPosted: Fri Mar 30, 2012 5:18 pm Reply with quote
Binary
Разработчик
Разработчик
Joined: 17 Dec 2004
Posts: 1712
Location: Омск




fk00 wrote:
Quote:
Да, но опенсорс здесь проигрывает по возможностям не потому, что его авторы не могут сделать так же хорошо, а потому, что для подобного рода софта нужны некоторые денежные вливания, которых взять негде.


я на это и намекал

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


Слишком абстрактно Wink

Quote:

Quote:
На что спорите?

на интерес Grin

не интересно.

Quote:

Quote:
Прекрасно, блин, а для домашних пользователей нужен STUN, и что теперь? О чём сей трёп? В корпоративной среде можно вообще без NAT traversal обходиться, чистым UDP-транспортом при нормальной настройке.


Quote:
Принципиальная ошибка в упомянутых "простых" стандартах это смешивание двух концепций - p2p и c2s. Это приводит к двум фундаментальным недостаткам: в корпоративной среде не выполняется принцип разделения информационной среды, а в SOHO секторе - все это просто плохо работает, потому что зоопарк и реализовано далеко не везде.


Quote:
Нет уж вы расскажите, пожалуйста, а то кругом обрывки фраз непонятного назначения и никакой конкретики.


не вопрос!
вам приятно будет писать шейпер для вот такой вот простенькой схемки?

С1 -----NAT------ S1 -----NAT------ S2 -----NAT-----C3
|
NAT
|
C2

Просьба также учесть 3 фактора:
1. Количество очередей с приоритетами порядка 50
2. Количество VLAN порядка 30
3. Файерволов порядка 6-10 в данном конфиге.

А как насчет настройки каждого софтового фаервола? Порт-маппинг? ISP не даст. Это, повторяю, корпоративная среда, где "настроить можно не все", так как хочется....

Я, конечно же, не рисовал Wi-Fi точки (UPnP, угу), stateless firewalls, WAN xDSL и пр. прелести сети, сильно отличающейся от домашней.

Попробуйте обеспечить непрерывность UDP потока в такой среде, не говоря уже о multicast/IGMP, который при ваших айсах тихо умрет, не выйдя из стадии зиготы.


Внимание вопрос: как jingle nodes решает данную проблему? Я всеми руками за IPv6 и избавление от костылей, которые привносятся благодаря IPv4, НО как jingle nodes вам поможет? Те же проблемы.

_________________
And I'm feeling good!
View user's profile Send private message Send Jabber-message Visit poster's website HabaHaba - Fast communicate
PostPosted: Fri Mar 30, 2012 5:27 pm Reply with quote
fk00
Начинающий тестер
Начинающий тестер
Joined: 27 Mar 2012
Posts: 22




Quote:

ejabberd умеет XEP-0065, но, насколько я понял (код не смотрел), только для file transfer
Вы неправильно поняли, ejabberd'у до лампочки, какой именно контент будет передаваться через SOCKS, XEP-65 этого не регламентирует.


Quote:
Всё верно, только вот XEP-65 нигде, кроме xmpp нет, так что проблемы с взаимодействием обеспечены. (UDP пока никто не умеет)


я так и подумал, но все же было подозрение, что транспортный протокол должен поддерживаться еще и на сервере
вы уверены, что этот XEP реализован поверх UDP в ejabberd?

Quote:

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

это обычный RTP proxy, который склеивает 2 потока (если больше - это уже конференция)
в моих мечтах это делает asterisk, выполняя только и исключительно эту функцию, тогда на клиенте реализация коференций становится простой и приятной процедурой - просто отсылай запросы на подключение

http://code.google.com/p/erlrtpproxy/
протестировал (не очень хорошо) как standalone, так и в виде модуля к ejabberd
не работает ни то, ни другое, пока оставил в покое, этим займусь после решения проблем с авторизацией


Quote:
TURN, по идее, тоже пройдёт любой фаерволл, так что зачем лишняя сущность, пока ума ни приложу.

повторяю, это для NAT и SOHO
в корпоративе routing и QoS

еще раз, p2p не годится, потому что надо пробивать множество фаерволов и это нарушение принципов безопасного разделения сред
почитайте о причинах возникновения проблем с Jingle на странице с Jingle Relay Nodes
первый нераспространен нигде из-за своих генетических проблем, второй - потому что скайп
View user's profile Send private message
PostPosted: Fri Mar 30, 2012 5:37 pm Reply with quote
Lion
Разработчик
Разработчик
Joined: 10 Jan 2005
Posts: 699
Location: г. Волжский




Зачем спорить? Каждый из способов имеет право на существование и они должны не заменять друг-друга, а дополнять. Для Вакуума куда важнее иметь транспорт, который позволит обеспечить связь в как можно больших конфигурациях нежели обеспечивающий разделение сред. Но модульная структура клиента позволит корпоративным пользователям удалить модуль с неустраиващим их транспортом и добавить свой.
View user's profile Send private message Send Jabber-message HabaHaba - Fast communicate ICQ Number
PostPosted: Fri Mar 30, 2012 5:48 pm Reply with quote
fk00
Начинающий тестер
Начинающий тестер
Joined: 27 Mar 2012
Posts: 22




Lion wrote:
Зачем спорить? Каждый из способов имеет право на существование и они должны не заменять друг-друга, а дополнять. Для Вакуума куда важнее иметь транспорт, который позволит обеспечить связь в как можно больших конфигурациях нежели обеспечивающий разделение сред. Но модульная структура клиента позволит корпоративным пользователям удалить модуль с неустраиващим их транспортом и добавить свой.

отнюдь! это скорее не спор, я просто хочу донести мысль о том, что
1. Не обязательно строго следовать стандартам, которые почти нигде не реализованы
2. Корпоративный клиент не может использовать существующие наработки, по изложенным причинам.

За сим, заполнив существующие лакуны в ассортименте продуктов, можно получить такой фидбэк, который трансформируется по желанию в деньги или портфолио, по выбору
Quote:
Но модульная структура клиента позволит корпоративным пользователям удалить модуль с неустраиващим их транспортом и добавить свой.


проблема в том, что такого модуля просто не существует в природе (если исключить довольно тормозной своеобразный jitsi)

Просто хочу привлечь внимание и готов помочь любым доступным мне способом (при тестировании их очень много).

Спасибо! Smile
View user's profile Send private message
PostPosted: Fri Mar 30, 2012 6:27 pm Reply with quote
fk00
Начинающий тестер
Начинающий тестер
Joined: 27 Mar 2012
Posts: 22




Quote:
Внимание вопрос: как jingle nodes решает данную проблему? Я всеми руками за IPv6 и избавление от костылей, которые привносятся благодаря IPv4, НО как jingle nodes вам поможет? Те же проблемы.

как вы понимаете, на ipv6 ради джаббера никто переходить не будет...

Проблема превращается в одну простую и элегантную: поставить RTP proxy и пробить для него канал.
Все.
NAT при такой схеме вообще никак не мешает, на всех фаерволах создается одно правило (ну, SRC, конечно, другой, но у нас enterprise, и это делается в одно движение), QoS настраивать - одно удовольствие, хотите шейпер на сервере - пожалуйста, хотите отдельный туннель через multiple uplink with failover - тоже не проблема

суть в разном подходе к транспортам при потоках и сообщениях, первое - это UDP, второе - TCP
разные транспорты - разная архитектура системы (хотя по сути - та же самая, и не p2p, как вы понимаете)

ну, для сравнения - это как одноранговая сетка в общаге и LDAP+Kerberos (если хотите, Active Directory)
View user's profile Send private message
PostPosted: Fri Mar 30, 2012 7:21 pm Reply with quote
Binary_
Guest




fk00 wrote:

как вы понимаете, на ipv6 ради джаббера никто переходить не будет...

Необходимость назрела далеко не со стороны джаббера...

Quote:
Проблема превращается в одну простую и элегантную: поставить RTP proxy и пробить для него канал.
Все.


Ну так TURN в зубы и вперёд, не?
PostPosted: Fri Mar 30, 2012 7:28 pm Reply with quote
fk00
Начинающий тестер
Начинающий тестер
Joined: 27 Mar 2012
Posts: 22




Binary_ wrote:
fk00 wrote:

как вы понимаете, на ipv6 ради джаббера никто переходить не будет...

Необходимость назрела далеко не со стороны джаббера...

Quote:
Проблема превращается в одну простую и элегантную: поставить RTP proxy и пробить для него канал.
Все.


Ну так TURN в зубы и вперёд, не?

вы не понимаете
TURN вообще для другого

я говорю, что по сути неважно как транслируются адреса и как эту проблему решать
есть гораздо более адекватно решение для любой корпоративной среды, которое не реализовано толком ни в одном клиенте - Jingle Relay Nodes.
при таком решении ставится один media proxy и неважно, как устроена сеть, есть там НАТ или сеть маршрутизируется
View user's profile Send private message
PostPosted: Fri Mar 30, 2012 7:36 pm Reply with quote
Binary_
Guest




fk00 wrote:

я так и подумал, но все же было подозрение, что транспортный протокол должен поддерживаться еще и на сервере
вы уверены, что этот XEP реализован поверх UDP в ejabberd?

эээ? сказал же, что UDP никто не умеет. Транспортного протокола нет как такового там, в случае передачи файла просто устанавливается поток и передаётся файл безо всяких прелюдий. Так что XEP-65 делает ровно одну задачу - устанавливает p2p поток между двумя клиентами, даже если они за NAT (причём, если возможно, используется прямое соедиенение, так что опять он мимо кассы с вашими непонятными мне проблемами, т.к. по сути является тем же TURNом, только топорнее).

Quote:
Quote:
TURN, по идее, тоже пройдёт любой фаерволл, так что зачем лишняя сущность, пока ума ни приложу.

повторяю, это для NAT и SOHO
в корпоративе routing и QoS


Иии? Какая конкретно проблема то? TURN это тот самый прокси, что вам так сильно хочется.

Quote:
еще раз, p2p не годится, потому что надо пробивать множество фаерволов и это нарушение принципов безопасного разделения сред
почитайте о причинах возникновения проблем с Jingle на странице с Jingle Relay Nodes
первый нераспространен нигде из-за своих генетических проблем, второй - потому что скайп


Где именно почитать? Почитал XEP и никаких противоречий со своими словами не нашел - relay nodes это всего-лишь ещё один NAT Traversal.
PostPosted: Fri Mar 30, 2012 7:37 pm Reply with quote
Binary_
Guest




fk00 wrote:
Quote:

Ну так TURN в зубы и вперёд, не?

вы не понимаете
TURN вообще для другого

попытаемся внести конкретики до продолжения демагогии. Для чего TURN?
PostPosted: Sat Mar 31, 2012 12:34 am Reply with quote
fk00
Начинающий тестер
Начинающий тестер
Joined: 27 Mar 2012
Posts: 22




Quote:
попытаемся внести конкретики до продолжения демагогии. Для чего TURN?

справедливо, я недостаточно точен в формулировках
Quote:
Traversal Using Relays around NAT (TURN) is a protocol that allows for an element behind a network address translator (NAT) or firewall to receive incoming data over TCP or UDP connections. It is most useful for elements behind symmetric NATs or firewalls that wish to be on the receiving end of a connection to a single peer. TURN does not allow for users to run servers on well known ports if they are behind a NAT; it supports the connection of a user behind a NAT to only a single peer. In that regard, its role is to provide the same security functions provided by symmetric NATs and firewalls, but to turn the tables so that the element on the inside can be on the receiving end, rather than the sending end, of a connection that is requested by the client.

В корпоративных сетях НЕ используется NAT как таковой, ибо привносит множество проблем, суть которых не имеет отношения к обсуждаемым вопросам

Quote:
эээ? сказал же, что UDP никто не умеет. Транспортного протокола нет как такового там, в случае передачи файла просто устанавливается поток и передаётся файл безо всяких прелюдий. Так что XEP-65 делает ровно одну задачу - устанавливает p2p поток между двумя клиентами, даже если они за NAT (причём, если возможно, используется прямое соедиенение, так что опять он мимо кассы с вашими непонятными мне проблемами, т.к. по сути является тем же TURNом, только топорнее).


здесь надо подробнее...
представьте себе подобную структуру, которая используется в корпортативной среде (если нужны объяснения, почему именно так, я предоставлю, но это out of scope)
геолокация(офис, логическая единица с точки зрения бизнес-процессов), отделенная двумя фаерволами разного назначения
ISA Server, которая не умеет даже connection tracking, и внешний аппаратный или софтовый фаервол на основе linux/unix/Cisco IOS. Допустим, везде есть правлильный full cone NAT. Компания следует Information Security Policy (ISP), которая запрещает движение информации между отдельными VLAN внутри каждого офиса. VLAN могут: NAT, firewalled tunneling и тп. ISP _запрещает любое движение информации между VLAN. То есть, внутри каждой геолокации (офиса) невозможны прямые p2p RTP сессии. Они маол того что невозможны, но еще и (ввиду того что ISA и прочие подобные умеют conntrack) и невозможно открывать диапазоны адресов 8000-30000 согласно спецификациям RTP протокола. Зато стандарты безопасности допускают открытие диапазонов адресов на одной точке (RTP Proxy). Это приемлемо, потому что дает централизованный контроль надо трафиком, который даже в случае firewall неприемлем ввиду принципппа разделения ролей (см. напр. PСIDSS стандарт) серверов. То есть, проще говоря, один сервер - одна роль. Мы фактически не можем навесить на фаервол роль RTP Proxy (он же MediaProxy). Таковы условия во многих корпоративных средах. Аутсорсинг (серьезный) - один из примеров. Обычно под каждый проект создается VLAN, к нему привязывается с учетом географического расположения подсеть, которая маршрутизируется и обязательно (!!!) фаерволится.

Надеюсь не вогнал в тоску Smile

Суть этого всего такова - в корпоративных средах принято по двум причинам обеспечивать контроль над трафиком по принципу сведения в одну точку (централизация), первая - безопасность, вторая - простота администрирования (QoS как пример).

TURN плох по одной причине. Даже если с точки зрения сетевого админа он выглядит как UDP/TCP прокси, он не поддерживает авторизацию/аутентификацию. Последняя реализуется на XMPP сервере.

Надеюсь, объяснил понятно. Прошу задавать вопросы, если где-то что-то неясно, проясню любые моменты.

Спасибо.
View user's profile Send private message
PostPosted: Sat Mar 31, 2012 6:48 am Reply with quote
Yagiza
Отметившийся
Отметившийся
Joined: 27 Mar 2012
Posts: 7
Location: г. Магнитогорск, Россия




Binary wrote:
Yagiza wrote:
По-моему, данная дорожная карта весьма состоятельна. Или Вы имеете какие-то возражения против такой последовательности?


Ага, имею. Использование SOCKS5 транспорта может помешать использовать готовые медиа-фреймворки, а ещё никто нынче не умеет этот транспорт использовать совместно с jingle, как тестировать прикажете?

Верите, нет? Не вижу никакой проблемы. В чём принципиальная разница использования SOCKS5 с Jingle и с SI/FT?

_________________
潔くカッコ良く生きて行こう!
View user's profile Send private message Send Jabber-message MSN Messenger ICQ Number
протокол Jingle
JRuDevels Forum Index » Vacuum
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT + 3 Hours  
Page 2 of 5  
Goto page Previous  1, 2, 3, 4, 5  Next
  
  
 Post new topic  Reply to topic  


Powered by phpBB © 2001-2004 phpBB Group
phpBB Style by Vjacheslav Trushkin