200 likes | 482 Views
Interprocess Communication in Distributed Computing. A Practical? Study Adam Albertson. What is Interprocess Communication?. In short, Interprocess communication is the ability for disparate process threads or elelements of a Distributed System to talk with itself. A Practical Example.
E N D
Interprocess Communication in Distributed Computing A Practical? Study Adam Albertson
What is Interprocess Communication? • In short, Interprocess communication is the ability for disparate process threads or elelements of a Distributed System to talk with itself.
A Practical Example • Today we will be touching upon a practical implimentation of a client-server distributed system, commonly known as Seti @ home.
Seti@Home? • Why are we using Seti@Home as an example? • Seti@Home utilizes InterProcess Communication in a transparent manner that’s easily referenced and referrable. • Availability – this and other @home projects generally share a similar methodology for passing information from Client to Server • Everyone likes Little Green Men • I Grok Spock!
Please leave the groans at the door… • The SETI @ Home project utilizes a mix of Asynchronous and Synchronous technologies when analyzing received RF signals from it’s antennas.
Beg Pardon? • Synchronous • Time • All RF captured for analysis is time-stamped for the interval it is received in. • Asynchronous • Chunking • RF samples is split into chunks and passed in bloc to individual SETI@Home machines for analysis and processing
Failing to see how this applies… • This data has to be handled properly with fairness and the expectation that data may not be received back from the clients in a timely manner or at all.
Oh. • Ergo the client-server model • The Server serves as a database and central hub for assigning and distributing Work Units to various Clients for processing & analysis • This data, once encapsulated and sent is chewed upon by the clients and a fairly basic binary T/F result is returned after the client has chewed upon their WU.
… • Having been returned with their T/F result, the SETI@Home servers compare results (Usually the same WO’s are sent to several machines, resulting in comparable results and redundancy) and decide if they have valid data. • If there is no valid data, the WO’s are sent out again for additional analysis, or are flagged for attention by Seti staff as something is amiss.
So how does… • TCP • WO’s between the client and server have to have reliable transfer of their Work Orders and results • Shared Memory • Internal to both the Client and Server, messages are passed between threads for both analysis of data and for passing results as needed • Resource Allocation • Demand-based system. As resources become available, they poll the SETI@Home servers for work. If there’s data available or WO results to verify, they get a WO to chew on. • Reliance on specific nodes not required as fluctuations on availability of the same is expected.
Details…? • Pick one. TCP? Fair enough… • TCP is a known and reliable networking protocall. Data, once sent, generally will get to it’s destination intact… eventually. • Data sent via TCP is in a set format, removing dependence upon a particular operating system or programming language as long as the data can be processed at the far end.
Specifics… and Conclusion. • Would take much more than 7 minutes to encapsulate and explain, however information regarding specific subsets of this process are readily available on the web. • Thank you for your attention.