90 likes | 212 Views
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.
E N D
Application Programming Interface forFuture 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
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
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
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
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
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)
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?
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