Successfully reported this slideshow.
Your SlideShare is downloading. ×

LADC 2009 - Student Forum

Upcoming SlideShare
resume khola (1) (1) (1) (1)
resume khola (1) (1) (1) (1)
Loading in …3

Check these out next

1 of 18 Ad

More Related Content

Similar to LADC 2009 - Student Forum (20)

Recently uploaded (20)


LADC 2009 - Student Forum

  1. 1. LADC 2009 - Student Forum<br />Providing security and a consistent failure detection semantic for asynchronous distributed objects<br />Rodrigo Vilar Miranda<br />Laboratório de SistemasDistribuídos<br />Universidade Federal de Campina Grande<br />
  2. 2. Introduction<br /><ul><li>Distributed systems complexity
  3. 3. Middleware
  4. 4. Security
  5. 5. Failure detection
  6. 6. The programmer can focus on system logic
  7. 7. Use of object oriented languages</li></li></ul><li>Introduction<br /><ul><li>Distributed objects model
  8. 8. Synchronous
  9. 9. Blocked thread
  10. 10. CORBA, Java RMI, .NET Remoting
  11. 11. Asynchronous model
  12. 12. Messages and queues
  13. 13. Low level primitives
  14. 14. XMPP</li></li></ul><li>Introduction<br /><ul><li>Hybrid approach
  15. 15. JIC - Java Internet Communication
  16. 16. Asynchronous distributed objects
  17. 17. Object Oriented API
  18. 18. Remote methods without return type and exceptions
  19. 19. Internet friendly
  20. 20. Simple failure detector
  21. 21. It was use in OurGrid 4 alpha
  22. 22. Gaps
  23. 23. Does not threat security issues
  24. 24. The FD can not detect message loss</li></li></ul><li>Commune<br /><ul><li>A JIC evolution
  25. 25. Flexible security portfolio
  26. 26. Connection protocol
  27. 27. Enables the FD to detect message loss
  28. 28. Some API enhancements</li></li></ul><li>Security<br />Many security mechanisms for systems over Internet<br />Authentication<br />Authorization<br />Encryption<br />Certification, etc.<br />Security versus Deployment simplicity <br />
  29. 29. Security<br />Commune provides a flexible security portfolio<br />Asymmetric cryptographic keys <br />Sign every message sent through Commune<br />Ensure the public key belongs to the message sender<br />X.509 certificates<br />Certification authorities <br />Guarantee the sender identity<br />
  30. 30. Security<br />Flexibility<br />By default, a Commune node automatically generates its own asymmetric key pair and a self-signed certificate<br />The default data can be replaced by real data<br />According to application security requirements <br />OurGrid 4 uses Commune security portfolio<br />Asymmetric cryptographic keys <br />Validate communication sessions<br />Implement a incentive mechanism<br />Certification <br />Optional use to manage peers relationships<br />
  31. 31. JIC Connection Model<br />A sender node (A) will send application messages to a receiver node (B)<br />A registers interest on B<br />The Failure Detector of A starts monitoring B<br />Push model<br />
  32. 32. JIC Connection Model<br />The Failure Detector notifies A when:<br />B becomes available (recovery)<br />B becomes unavailable (failure)<br />Control channels for Failure Detector messages<br />Data channel for Application messages<br />Can detect only crash failures<br />No not detect message loss<br />
  33. 33. Commune Connection Protocol<br />Consistent failure detection semantic<br />Can detect message loss<br />Requirement 1<br />There are two nodes, A that is interest in B, so: <br />If A and B are available, <br />eventually a connection from A to B will be established, <br />and will continue established while <br />A and B were available and <br />no messages were lost in the communication layer<br />
  34. 34. Commune Connection Protocol<br />After the establishment of a connection between A and B, so:<br />Requirement 2<br />If B fails, eventually A will be notified<br />Requirement 3<br />If a message was lost, <br />3.1 eventually A will be notified of B failure and, <br />3.2 if there is also a connection from B to A, <br />eventually B will be notified of A failure<br />
  35. 35. Commune Connection Protocol<br />Connection session number<br />Random generated during interest registration<br />Sequence number<br />Zero in the session creation<br />Incremented when a application message is sent<br />Requirements 1, 2 and 3.1<br />
  36. 36. Commune Connection Protocol<br />Reverse connections<br />Duplicated and independent data structures<br />Exception: Requirement 3.2<br />
  37. 37. Connection Protocol Tests<br />Spin <br />Formal verification tool<br />Promela modeling language<br />2 Nodes with state machines<br />4 Channels<br />
  38. 38. Connection Protocol Tests<br />Results:<br />From the initial model, there are not deadlocks neither unreachable states<br />From any possible state, there are not deadlocks neither unreachable states<br />It is possible to reestablish the connection<br />We performed 456976 verifications using Spin<br />13 possible states in A / 13 possible states in B<br />13 possible kinds of messages in the outgoing channels<br />4 possible kinds of messages in the incoming channels<br />
  39. 39. Conclusion<br />JIC security gaps were resolved<br />Definition and tests of a consistent failure detection mechanism<br />Connection Protocol implementation<br />Future work<br />Unit and system tests<br />OurGrid 4.2 – with Connection Protocol<br />
  40. 40. Questions?<br />Rodrigo Vilar Miranda<br /><br />