Changes between Version 3 and Version 4 of Master Slave Protocol
- Timestamp:
- Jun 16, 2005, 4:59:03 PM (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Master Slave Protocol
v3 v4 4 4 5 5 To decouple the master and slave, an application protocol will be defined on top of the meta-protocol BEEP (Blocks Extensible Exchange Protocol, [http://www.faqs.org/rfcs/rfc3080.html RFC 3080]). BEEP was chosen because it provides peer-to-peer communication (so that both the client and the server can send requests to the other) and because of its relative simplicity compared to protocols such as XMPP. 6 7 == Why BEEP? == 8 9 I first looked [http://www.jabber.org/ Jabber]/[http://www.xmpp.org/ XMPP], but it seemed to be very complex (with dozens of related specifications), and there are no sufficiently mature implementations for Python. I could live with the complexity, but not if I have to implement the whole stack myself. I didn't look into other IM protocols because I wanted to build on something open/standardized. Note that even if I'd chosen XMPP/etc I would have to design a protocol on top of the provided infrastructure. 10 11 BEEP is simple and flexible, and explicitly designed as a foundation for custom application protocols. While the only Python implementation I found ([http://beepy.sourceforge.net/ BEEPy]) uses [http://twistedmatrix.com/ Twisted] and looks dead, BEEP is really simple enough to be implemented in a basic way in the scope of this project (i.e. minus 12 the authentication and security features, which ''could'' of course be added later). 6 13 7 14 == Slave Registration == … … 20 27 Content-Type: application/beep+xml 21 28 22 < sysinfoname="levi" maintainer="Christopher Lenz <cmlenz@gmx.de>">23 <platform family="powerpc">Power Macintosh</platform>29 <register name="levi" maintainer="Christopher Lenz <cmlenz@gmx.de>"> 30 <platform>Power Macintosh</platform> 24 31 <os family="posix" version="8.1.0">Darwin</os> 25 </ sysinfo>32 </register> 26 33 END 27 34 }}} … … 63 70 64 71 After a build step has been completed, the client transmits the data generated (as identified by the {{{<reports>}}} in the recipe) to the server, along with the the output of the build and a success/failure flag. 72 73 == Error Handling == 74 75 A build slave can abort the build whenever it wants (announcing it and saying goodbye), or it can just disconnect (as would happen on a hard shutdown of the machine). Both can be easily detected by the build master, in which case it will choose the next client from its list that matches the given requirements. 76 77 Another case to deal with is timing out when the client started a build but fails to respond for an exceptionally long period of time. The server would then disconnect, and choose the next available slave, as above. The timeout would have to be configurable, as it may vary significantly between projects.