Monday, January 21, 2013
Week 3
Implementing Remote Procedure Calls A. Birrell and D. Nelson
This paper describes the overall structure of the RPC mechanism.
In this paper the authors introduce remote procedure calls. RPC is seemed as an extension on procedures executed in another address space on a single computer. RPC transfers the control and data across a communication network. It can be provided in a high-level language, and the programmer does not need to worry about the details of remote interaction. RPC is widely used in many areas.
The many faces of publish/subscribe P. Eugster, P. Felber, R. Guerraoui and A-M. Kermarrec
In this paper the authors discuss about the publish/subscribe interaction scheme and its variants, as well as some alternative interaction schemes.
The authors propose the common denominators of publish/subscribe schemes, namely time, space and synchronization decoupling of subscribers and publishers. They survey several interaction scheme such as RPC and message queuing. The conclude that publish/subscribe scheme supports better for time, space and synchronization decoupling than any of those methods. Meanwhile, They compare two widely used schemes, topic-based and content-based. In this scheme, publishers and subscribers are loosely coupled. Moreover it provides better scalability.
Security issue might be a disadvantage of publish/subscribe scheme. It is possible that a client fools the middleware medium so that it could receive the information it is not authorized to receive.
Subscribe to:
Post Comments (Atom)
Security is an interesting issue that I hadn't given much thought. Usually in the publish/subscribe model, you think about technologies like RSS, in which man-in-the-middle type attacks aren't really that concerning due to the insensitive nature of the data. However in a more general usage of this scheme, I can see how that would be a problem.
ReplyDeleteOne thing I wish the authors had expanded upon is the potential advantages of the publish/subscribe scheme over other schemes. They mention that, due to different abstractions, different schemes are hard to compare, but I would have liked to see more information on why the publish/subscribe scheme would be chosen, and in what instances.
The Many Faces of Publish/Subscribe really peaked my interest because I worked at a high frequency trading firm over the summer, and I was very interested in how they described the systems. Although I can imagine systems that follow some of the other models described here, the closest to what I worked on was the content based publish/subscribe system. The currency exchanges that I worked on had the following properties: udp transfer of information on a private internet (based on the itch framework, but different https://docs.google.com/viewer?a=v&q=cache:BmkLGaCbDRwJ:https://www.nasdaqtrader.com/content/technicalsupport/specifications/dataproducts/tvitch-v4.pdf+&hl=en&gl=us&pid=bl&srcid=ADGEESiUaqVTvMoCmCZhGmDVnaB6chJgd_GO5VmO3Ibfl7F8CnYUyn7GzPlcc12vw1B2AnpJUmH8DhKCsDGVHYCxHV-ytSFwA70rMrkb08gaOPMhrzE0gE79cxKJdLM-ILIkKn7tajQq&sig=AHIEtbQjdfFakqKEIdNkPYJh9KYnm3vK3Q) . This means that there were two channels. One specification for buying and selling, and completely different protocol for subscribing to "the book" which was a representation of the current prices. When you connected to the service, you were given a list of stocks you can subscribe to. Then you tell the system which ones you want to subscribe to, and the system will send you a feed of data for that stock.
ReplyDelete<3
Jon