1 / 9

Application Programming Interface for Future Pub/Sub Networks

Application Programming Interface for Future Pub/Sub Networks. Dr. Dmitrij Lagutin Helsinki Institute for Information Technology (HIIT) 27.9.2011. Contents. Requirements for a pub/sub API Examples of APIs in PSIRP and PURSUIT prototypes Ideas for a future pub/sub API Conclusions.

meara
Download Presentation

Application Programming Interface for Future Pub/Sub Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Application Programming Interface forFuture Pub/Sub Networks Dr. Dmitrij Lagutin Helsinki Institute for Information Technology (HIIT) 27.9.2011

  2. Contents • Requirements for a pub/sub API • Examples of APIs in PSIRP and PURSUIT prototypes • Ideas for a future pub/sub API • Conclusions

  3. Requirements for a pub/sub API • Current TCP/IP-based API (socket) is quite old, and does not take into account many requirements of current applications • Applications are dealing with information, which is structured and linked • API should not depend on the location or used network • API should offer a way to access various services and large amounts of data in an efficient way • Future pub/sub network can also give much higher degree of control to the user or developer, which also should be taken into account in API • Used transit path, security policy, quality-of-service

  4. Examples: PSIRP Prototype API • High-level API resembles standard memory and socket operations: malloc, mmap, socket, send, recv, select • Scopes are created implicitly • handle = create (size) • Creates a pointer to data and metadata of a specific size, of a memory object to be published • publish (sid, rid, handle) • Publishes a read-only version of the object • handle = subscribe (sid, rid) • Subscribes to the object • events = listen (handle) • Listens to publication events, i.e., new versions

  5. Examples: PSIRP Prototype API • Publications are also accessible through file system • /pubsub/sid/rid/data and /pubsub/sid/rid/metadata • Legacy applications (text editor, web browser, file utilities) can access the data • Writing or deleting through file system is not supported

  6. Examples: PURSUIT Prototype API • Most functions takes following arguments: id, prefix_id, strategy, lid • publish_scope, publish_info • Creates a scope or advertises information items (publications) • publish_data (id, strategy, FID, data, data_len) • Publishes data for a specific information ID • subscribe_scope, subscribe_info • Subscribes to scope or to information items • unpublish_scope, unpublish_info • Unpublishes scope or information items • unsubscribe_scope/unsubscribe_info • Unsubscribes from scope or information item

  7. Examples: PURSUIT Prototype API • Publication strategy • Determines how the information is disseminated, where it will be visible, etc. • DOMAIN_LOCAL (visible only in local domain) • PUBLISH_NOW (sends the data immediately, even if there are no subscribers)

  8. Other ideas • A simple way to publish, subscribe and manage publications, which similar to full-featured file system or Dropbox • Natural support for streams • Dividing API into two levels • High-level simple API with few basic functions such as publish or subscribe • More fine-grained API for controlling rendezvous and other pub/sub-related functionality (transit paths, security policies, quality-of-service, etc.) • Any other ideas?

  9. Conclusions • Efficient API for future pub/sub networks is still an open problem • Additional reading • P. Pietzuch, D. Eyers, S. Kounev, and B. Shand. Towards a Common API for Publish/Subscribe, DEBS 2007. http://dl.acm.org/citation.cfm?id=1266924 • M. Demmer, K. Fall, T. Koponen, and S. Shenker. Towards a Modern Communications API, HotNets-VI.http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.138.8926

More Related