XMPP/Jingle(VoIP)/Perl Ocean 2012/03

1,860 views
1,673 views

Published on

Perl Oceanを作成したときの資料

XMPP/Jingleなどのプロトコルの説明や、古いブラウザやWebSocketのような新技術とのインテグレーションについて

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,860
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

XMPP/Jingle(VoIP)/Perl Ocean 2012/03

  1. 1. Ocean XMPP Based Realtime Communication Framework Suite ! 加藤 亮 2012/03
  2. 2. Realtime • Data (micro contents) • Delivery Method ( Push ) • UI
  3. 3. PUSH Friendly Contents • Notification • Activity Stream • Message, Chat • Presence
  4. 4. PUSH • Long Polling • XMPP • HTML5 (SSE, WebSocekt) • Smart phone (APNS, C2DM)
  5. 5. UI • Ajaxify - auto view updating
  6. 6. Ocean
  7. 7. Framework Suite • Front Server • Cluster • HTTP Binding • P2P(Audio/Video chat) 予定
  8. 8. Protocol • • XMPP Based • XMPPのサブセットをサポート XMPPと内部で互換性を持たせた数種類の独自 プロトコル • • External WebSocket Binding HTTP Binding ( WebSocket/SSE/XHR )
  9. 9. Jabber/XMPP
  10. 10. examples • google talk • facebook chat • PSN • iMessage • google wave ( S2S )
  11. 11. Stream Procedure • Stream Initialization • TLS Negotiation • Authentication • Resource Binding • Session Establishment • Roster Request • Initial Presence
  12. 12. Stanza • Feature • Auth • Message • Presence • IQ
  13. 13. ID • JID (example: lyokato@mixi.jp/resource ) • Full JID (lyokato@mixi.jp/resource) • Bare JID (lyokato@mixi.jp)
  14. 14. Authentication • SASL • DIGEST-MD5 • PLAIN ( under TLS ) • EXTERNAL ( for S2S TLS ) • We need • OAuth 2.0? • Cookie/Ticket ( for WebSocket )
  15. 15. Message
  16. 16. Message • service notification (type=headline) • chat message (type=chat) • group chat message (type=groupchat) • normal ? message (type=message)
  17. 17. Presence
  18. 18. Presence • presence • subscription • Ocean doesn’t support subscription • extension • join/leave a room
  19. 19. Presence • show (chat, away, dnd, xa ) • status (custom message) • priority
  20. 20. Presence traps • protocol design • presence:connection = 1:1 • de facto usage • presence:user = 1:1
  21. 21. Presence De Facto Usage • one presence for one user • we don’t need priority • ‘chat’ and ‘away’ are enough for ‘show’ param
  22. 22. Resource Binding • node@domain/resource • you can choose ‘home’ or ‘work’ • de facto usage • users and client softwares don’t mind what the resource is. • so server generates random string (like a cookie )
  23. 23. Session Establishment • Historical Reason • Do nothing
  24. 24. IQ • Roster ( Friend List ) • vCard ( Profile ) • bind, session, ping, disco, etc... • packets should be back to sender
  25. 25. Roster & vCard • like OpenSocial’s ‘People Data API’
  26. 26. Roster • there isn’t profile image, which is included in vCard • no pagination control by default
  27. 27. vCard traps • just for profile image • but base64 encoded binary • we want URL
  28. 28. Subscription & Roster Push • Friend Request • Relationship State Control
  29. 29. C2S & S2S • Client to Server • Server to Server • Ocean doesn’t support S2S
  30. 30. C2S Example gmail C2S Stream User A C2S Stream User B
  31. 31. S2S Example S2S Stream chat.facebook.com gmail.com User A User B User C User D
  32. 32. S2S Problems • We have to manage new database that represents ‘relationships’ between users of our service and ones of other service. • We have to manage a white list or spam control. ( like OpenID ) • Authentication Compatibility Cost • Scaling Cost • Error Handling
  33. 33. Implementation
  34. 34. Other Implementations • I/O Multiplexing • Node.js • Apache MINA, naggati • Jabber/XMPP software • ejebberd • DJabberd • Openfire
  35. 35. Ocean’s XMPP support • subset • customized • fixed features(not pluggable ) • assumed cluster installation
  36. 36. Why subset? • Ocean is just for Web-based Social Network Service • Create/Modify friendships on the web site. • S2S costs too much • Developers have to write only minimum number of event handlers.
  37. 37. Protocol Customized • resource binding & roster/vCard responses support extra-attributes. • Because of regardless of HTTP federation, especially URL • WebSocket binding (experimental ) • try demo application • Simple-MUC
  38. 38. Not flexible and pluggable? • It may cause complication. requires detailed protocol knowledge, framework knowledge. • When the servers are distributed, frontserver-plugins require complicated spec. See ‘Cluster’ section. • There are de-facto-standard specs.
  39. 39. Why full scratch? • Proprietary Reason • We may need non-standard features • Rapid Updating (community based development requires many arguments) • Architectural Dependencies • No Money
  40. 40. Inside Ocean
  41. 41. Getting Started • All you need to do is ... • generate project template • edit configuration file • prepare your handler class
  42. 42. Generate Project Template • • ./ocean cd Foobar
  43. 43. Configuration • vi conf/ocean.yml
  44. 44. Write Handler Class • inherit Ocean::Handler • implement all event handler methods
  45. 45. Ocean Components Daemonizer Signal Handler Handler Listener Server Stream Stream Builder Stream Manager Stream Stream
  46. 46. Inside Stream Handler Server Stream Manager Stream Components Protocol States IO Components SASL Encoder Events Socket Decoder Client Active ...
  47. 47. Problem? • Bad performance • too many call stack on each event • each component consume memory
  48. 48. Benefit • Testability • You can switch to stub components • Customizability • You can switch Encoder/Decoder
  49. 49. Pay attention to memory usage • 4byte on a Stream object • 4x10,000byte on a Server witch has 10,000 connection • bless Array instead of Hash • use Config instance as singleton object • use delegate object for event handling
  50. 50. Handler Handler Connection Info User A User A User B User C Home Work Home Home chat away chat chat Users Relationships Databases Profile Pictures Files Your Service
  51. 51. Handler uses 2 or 3 kinds of store • Persistent Data Store (users, relationships) • Half Persistent Data Store. Same lifecycle as XMPP service (connection map) • Cache system ( if needed )
  52. 52. Handler Implementation
  53. 53. Handler Example • modules under Ocean::Standalone::Handler namespace are good example
  54. 54. Server Events • on_node_init • on_node_exit
  55. 55. Stream Events • on_sasl_auth_request
  56. 56. Stream Events • on_bind_request
  57. 57. Stream Events • on_message
  58. 58. Stream Events • on_presence • on_initial_presence • on_unavailable_presence
  59. 59. Presence doesn’t scale • user_001 login-ed ( send initial-presence ) • get all friends of user_001 • get all available-resources of the friends • send user_001’s presence to all the available-resources. • send presences of the all availableresources to user_001 It’s important to limit the maximum number of friends.
  60. 60. Stream Events • on_silent_disconnection
  61. 61. Stream Events • on_oster_request
  62. 62. Stream Events • on_vcard_request
  63. 63. Stream Events • on_too_many_auth_attempt
  64. 64. Start & Stop • bin/ocean-start • bin/ocean-start --daemonize • bin/ocean-stop ( if daemonized )
  65. 65. Cluster • C10K Problem on Persistent Connection • Blocking IO multiplexing • Message delivery/Presence broadcast
  66. 66. Message Delivery Connection Map User A User A User B User C Home Work Home Home 1 2 1 2 Delivery Server XMPP Server 2 XMPP Server 1 User A (Home) User B (Home) User A (Work) User C (Home)
  67. 67. Use 2 kinds of gearman • Background Job Dispatcher • Inbox ( 1 inbox for each front-server )
  68. 68. Message Delivery Connection Map User A User A User B User C Home Work Home Home inbox1 (gearmand) XMPP Server 1 1 2 1 2 Delivery Server Background Job Dispatcher (gearmand) inbox2 (gearmand) XMPP Server 2
  69. 69. Message Delivery Connection Map User A User A User B User C Home Work Home Home inbox1 (gearmand) XMPP Server 1 1 2 1 2 Delivery Server Background Job Dispatcher (gearmand) inbox2 (gearmand) XMPP Server 2
  70. 70. Message Delivery Connection Map User A User A User B User C Home Work Home Home inbox1 (gearmand) XMPP Server 1 1 2 1 2 Delivery Server Background Job Dispatcher (gearmand) inbox2 (gearmand) XMPP Server 2
  71. 71. Connection Map • too many ‘read’ • ‘write’ on resource-binding, presencechange • Implementation • TokyoTyrant • HandlerSocket • must not be volatile
  72. 72. Ocean::Cluster • Ocean::Cluster::Gearman::Server • Ocean::Cluster::Gearman::Worker
  73. 73. Cluster support on front server • set config ‘handler_class=Ocean::Cluster::Gearman::S erver::Handler’ • set inbox and background-job-dispatcher
  74. 74. Front server components Background Job Dispatcher (gearmand) inbox (gearmand) Ocean::Cluster::Gearman::Server::Handler XMPP Server
  75. 75. Build worker project ! • same as front server • build project-template • edit configuration • write your handler class
  76. 76. Generate Project Template • • ocean_cluster_gen --project=FooWorker --handler=FooWorker::Handler cd FooWorker
  77. 77. Configuration • set information about all your inboxes • set information about background-jobdispatcher
  78. 78. Worker side (delivery server) components Process Manager Connection Map Handler User A User A User B User C Serializer 1 2 1 2 Deliverer Subscriber DB (users, relationships, etc...) Worker Background Job Dispatcher (gearmand) Home Work Home Home inbox0 (gearmand) inbox1 (gearmand)
  79. 79. Transaction • 同じユーザーからのイベント順序が壊 れないように調整が必要
  80. 80. Operation
  81. 81. Balancing • Round-Robin • DNS SRV Record • • _xmpp_client._tcp.chat.mixi.jp 86400 IN SRV 10 20 5222 chat1.mixi.jp _xmpp_client._tcp.chat.mixi.jp 86400 IN SRV 10 5 5222 chat2.mixi.jp
  82. 82. Service Status Store name chat1 chat2 chat3 connections 100000 1000 100000 Service Status API and Client Hack wait 2 1 2 Update Periodically Status API chat1.mixi.jp User A (Home) chat2.mixi.jp chat3.mixi.jp
  83. 83. Service Status Store name chat1 chat2 chat3 connections 100000 1000 100000 Service Status API and Client Hack wait 2 1 2 Update Periodically Status API chat1.mixi.jp User A (Home) chat2.mixi.jp chat3.mixi.jp
  84. 84. Service Status Store name chat1 chat2 chat3 connections 100000 1000 100000 Service Status API and Client Hack wait 2 1 2 Update Periodically Status API chat1.mixi.jp User A (Home) chat2.mixi.jp chat3.mixi.jp
  85. 85. Update & Reboot • Worker side handler includes service-code, so it’s required updating and rebooting frequently. Worker’s job is stateless. So, it’s no problem. • Front-end server doesn’t include service- code. So you don’t need to reboot it frequently, but when you want to do it, you have to pay attention.
  86. 86. Shutdown • You can’t shutdown server without client awareness. • You have to write re-connection on client side code • Problem: algorithm distribution case • At graceful shutdown, unavailable presences are handled correctly • Problem: at non-graceful shutdown
  87. 87. Front-server Broken • フロントがぶっ壊れたときのために、 ConnectionMapから、壊れたサーバーに つないでたユーザー全員のunavailable presenceを処理するバッチを用意する必 要がある
  88. 88. Front-server maintainance • algorithm分散のフロントを定期再起動 するときは、代替が先に必要 • group_id = get_group(user_id) • host = get_host(group_id) • 代替サーバーを準備し、group/host マップを書き換えてから、shutdown
  89. 89. Service(Client-side) Strategy
  90. 90. Device/Platform • PC Web ( HTTP Binding ) • PC Desktop App(AIR, Titanium, or Native) • Smartphone • Tablet • Browser extension
  91. 91. Service • 1to1 Messaging • Room? (group chat) • Voice/Video chat • Push Notification
  92. 92. Ocean supports • WebSocket hybi-draft-10 support • HTTPBinding(WebSocket/SSE/XHR)
  93. 93. HTTP Binding
  94. 94. Methods • Polling ( Ajax ) + Post API (+APNS|C2DM) • Long Polling ( Ajax, Comet ) + Post API • ServerSentEvent + Post API • WebSocket • TCP XMPP
  95. 95. ‘Stateless’ problems • Different way of connection management from ordinary persistent connection • single user-session may open many tabs • user moves in short time. too many reconnection • how to detect user to leave? (leave or move)
  96. 96. Connection Map User A User A User B User C Home Work Home Home 1 2 1 2 too many ‘write’ and ‘presence’ in short time server 1 open many tabs or hop http-link in short time Tab User A server 2 server 3 mod_proxy(_balancer) Tab Tab User B when user leaves?
  97. 97. Solution 1 Algorithm Based Distribution • ユーザー毎の宛先を固定することによっ て、Connection Mapを利用しなくても、 特定のユーザーにパケットを届けるこ とは可能になる • ユーザーがWebサービスを開いてるか どうかは関係なくなる
  98. 98. Problem • Connection Mapを利用しないと、正確な プレゼンスを把握できなくなる
  99. 99. Solution 2. Stream Aggregation • 同一cookieを持つ接続をまとめあげる Sessionオブジェクトを利用する • 状態管理はSessionオブジェクトで工夫 • Pending TimerでLeaveの検知
  100. 100. Connection Map User A User A User B User C Aggregate connections as single session hb1.mixi.jp Home Work Home Home 1 2 1 2 hb2.mixi.jp Manager hb3.mixi.jp Manager use timer to detect users to leave. Manager until the expiration, server should buffer messages if received algorithm based distribution: server_node=algorithm(user_id) Tab Tab Tab Tab User A Tab Tab User B User C (*) number of simultaneous Ajax request directed to same domain is limited, so we need many nickname for each hb servers. (if we adopt long polling)
  101. 101. Handle Multiple Streams as One Single Session Handler Server Session Stream Manager ResourceBinding SessionEstablishment Session InitialPresence User A Stream User A Stream User B Stream User B Stream Handshake Auth
  102. 102. Tasks • We need to • prepare social ad system • improve UI (moveless)
  103. 103. PubSub Support • XEP-0061 Publish Subscribe • We don’t need full-spec support • don’t allow use to publish/subscribe • server publish event
  104. 104. Publish Event from Web Service Delivery Server XMPP Server 1 User A (Home) User B (Home) UserEvents (Notification, Activity) Web Service XMPP Server 2 User A (Work) User C (Home)
  105. 105. Web Service UserEvents (Notification, Activity) DeliveryCondition: ContentKind, UserPresence WebHook PubsubHubbub C2DM XMPP (HTTPBinding) Streams APNS Email
  106. 106. Groupchat
  107. 107. Overview • XMPP has MUC extension spec. but it’s over spec, so we need arrangement • Costs too much like presence • limit numbers of channels and participants • Static-type groupchat should keep synchronicity with ‘group(room?)’ feature on our service
  108. 108. Video/Voice Chat
  109. 109. Problem? • Isn’t Identity Association enough? • AccountManage (android) • FaceTime (iOS)
  110. 110. VoIP Signaling Server Signaling Channel Signaling Channel RTP Peer A Peer B Data Channel(Audio,Video)
  111. 111. VoIP Signaling Server Cant’ get PeerB’s Transport Address Cant’ get PeerA’s Transport Address RTP NATs Peer A NATs Peer B
  112. 112. NAT Traversal
  113. 113. Hole Punching 1. Local host connects to an external host NATs Local Host
  114. 114. Hole Punching 1. Local host connects to an external host 2. NAT allocates a transport address to localhost 10.100.100.100:10002 NATs MAPPING Local Host 192.168.0.1:10001
  115. 115. Hole Punching 1. Local host connects to an external host 2. NAT allocates a transport address to localhost 10.100.100.100:10002 NATs MAPPING Local Host 192.168.0.1:10001
  116. 116. Hole Punching 1. Local host connects to an external host 2. NAT allocates a transport address to localhost 3. An external host can send packet to local host through mapped global address NATs Local Host But every NAT doesn’t work as expected
  117. 117. STUN STUN Server Server Reflexive Transport Address NATs Host Transport Address STUN Client
  118. 118. STUN STUN Server Signaling Server STUN Server Do Hole Punching And Obtain Reflexive Address NATs Peer A NATs Peer B
  119. 119. STUN STUN Server Signaling Server STUN Server Exchange Obtained Reflexive Address Through Signaling Server NATs Peer A NATs Peer B
  120. 120. STUN STUN Server Signaling Server STUN Server Direct Communication Path NATs Peer A NATs Peer B
  121. 121. TURN Signaling Server relay packet NATs Peer A TURN Server NATs Peer B
  122. 122. TURN Relayed Transport Address TURN Server NATs Server Reflexive Transport Address NATs Host Transport Address TURN Client Remote Peer
  123. 123. TURN Relayed Transport Address TURN Server NATs Remote Peer Server Reflexive Transport Address NATs TURN Client Allocation Client ReflexiveTransport XXX.XXX.XXX.XXX:10001 XXX.XXX.XXX.XXX:10001 XXX.XXX.XXX.XXX:10002 Relayed Transport YYY.YYY.YYY.YYY:10001 YYY.YYY.YYY.YYY:10002 YYY.YYY.YYY.YYY:10003
  124. 124. TURN Relayed Transport Address TURN Server NATs Remote Peer A NATs Remote Peer B NATs Remote Peer C NATs TURN Client
  125. 125. TURN TURN Server NATs TURN Client NATs Remote Peer Channel Binding Client ReflexiveTransport XXX.XXX.XXX.XXX:10001 XXX.XXX.XXX.XXX:10001 XXX.XXX.XXX.XXX:10002 Number Relayed Transport 0x4001 YYY.YYY.YYY.YYY:10001 0x4002 YYY.YYY.YYY.YYY:10002 0x5001 YYY.YYY.YYY.YYY:10003 TODO: need peer reflexive address?
  126. 126. XMPP Jingle • Signaling on XMPP
  127. 127. Serverless Messaging
  128. 128. Protocols • UPnP • Bonjour(Rendezvous)
  129. 129. Bonjour • mDNS • DNS-SD
  130. 130. Find Friends • search service by DNS PTR records • search host for indicated service by SRV records • search IP address by A record • (TXT records for capability and status)
  131. 131. TODO • backward compatibilityの確保(iChat, etc) • 現在の要件への現実的な対応 (HTTPBinding) • 将来の準備(WebRTC)

×