Beginning Python - From Novice to Professional
Beginning Python - From Novice to Professional Beginning Python - From Novice to Professional
CHAPTER 27 ■ ■ ■ Project 8: File Sharing with XML-RPC In this chapter, you write a simple file sharing application. You may be familiar with the concept of file sharing from such applications as Napster (no longer downloadable in its original form), Gnutella (available from http://www.gnutella.com), BitTorrent (available from http:// www.bittorrent.com), and many others—what you’ll be writing is in many ways similar to these, although quite a bit simpler. The main technology you’ll use is XML-RPC. As discussed in Chapter 15, this is a protocol for calling procedures (functions) remotely, possibly across a network. If you want, you can quite easily use plain socket programming (possibly using some of the techniques described in Chapter 14 and Chapter 24) to implement the functionality of this project. That might even give you better performance because the XML-RPC protocol does come with a certain overhead. However, XML-RPC is very easy to use, and will most likely simplify your code considerably. What’s the Problem? What you want to create is a peer-to-peer file sharing program. File sharing basically means exchanging files (everything from text files to sound clips) between programs running on different machines. Peer-to-peer is a buzzword that describes a type of interaction between computer programs, as opposed to the common client–server interaction, where a client may connect to a server but not vice versa. In a peer-to-peer interaction, any peer may connect to any other. In such a (virtual) network of peers, there is no central authority (as represented by the server in a client–server architecture), which makes the network more robust. It won’t collapse unless you shut down most of the peers. ■Tip If you’re interested in learning more about peer-to-peer systems, you should do a Web search on the phrase “peer-to-peer,” which ought to give you several interesting hits. 499
500 CHAPTER 27 ■ PROJECT 8: FILE SHARING WITH XML-RPC Many issues are involved in constructing a peer-to-peer system—this project takes a very simple approach to things. In a system such as Gnutella, a peer may disseminate a query to all of its neighbors (the other peers it knows about), and they may subsequently disseminate the query further. Any peer that responds to the query can then send a reply through the chain of peers back to the initial one. The peers work individually and in parallel. (More recent systems, such as BitTorrent, use even more clever techniques, for example, requiring that you upload files in order to be allowed to download files.) To simplify things, your system will contact each neighbor in turn, waiting for its response before moving on. Not quite as efficient, but good enough for your purposes. Also, most peer-to-peer systems have clever ways of organizing their structure—that is, which peers are “next to” which—and how this structure evolves over time, as peers connect and disconnect. You’ll keep that very simple in this project, but leave things open for improvements. Specific Goals Here are some requirements that your program must satisfy: • Each node must keep track of a set of known nodes, from which it can ask for help. It must be possible for a node to introduce itself to another node (and thereby be included in this set). • It must be possible to ask a node for a file (by supplying a file name). If the node has the file in question, it should return it; otherwise it should ask each of its neighbors in turn for the same file (and they, in turn, may ask their neighbors). If any of these have the file, it is returned. • To avoid loops (A asking B, which in turn asks A) and to avoid overly long chains of neighbors asking neighbors (A asking B asking. . . asking Z), it must be possible to supply a history when querying a node. This history is just a list of which nodes have participated in the query up until this point. By not asking nodes already in the history, you avoid loops, and by limiting the length of the history, you avoid overly long query chains. • There must be some way of connecting to a node and identifying yourself as a trusted party. By doing so, you should be given access to functionality that is not available to untrusted parties (such as other nodes in the peer-to-peer network). This functionality may include asking the node to download and store a file from the other peers in the network (through a query). • You must have some user interface that lets you connect to a node (as a trusted party) and make it download files. It should be easy to extend and, for that matter, replace this interface. All of this may seem a bit steep, but as you’ll see, implementing isn’t all that hard. And you’ll probably find that once you’ve got this in place, adding functionality of your own won’t be all that difficult either.
- Page 479 and 480: 448 CHAPTER 23 ■ PROJECT 4: IN TH
- Page 481 and 482: 450 CHAPTER 23 ■ PROJECT 4: IN TH
- Page 483 and 484: 452 CHAPTER 23 ■ PROJECT 4: IN TH
- Page 486 and 487: CHAPTER 24 ■ ■ ■ Project 5: A
- Page 488 and 489: CHAPTER 24 ■ PROJECT 5: A VIRTUAL
- Page 490 and 491: CHAPTER 24 ■ PROJECT 5: A VIRTUAL
- Page 492 and 493: CHAPTER 24 ■ PROJECT 5: A VIRTUAL
- Page 494 and 495: CHAPTER 24 ■ PROJECT 5: A VIRTUAL
- Page 496 and 497: CHAPTER 24 ■ PROJECT 5: A VIRTUAL
- Page 498 and 499: CHAPTER 24 ■ PROJECT 5: A VIRTUAL
- Page 500 and 501: CHAPTER 24 ■ PROJECT 5: A VIRTUAL
- Page 502 and 503: CHAPTER 24 ■ PROJECT 5: A VIRTUAL
- Page 504 and 505: CHAPTER 25 ■ ■ ■ Project 6: R
- Page 506 and 507: CHAPTER 25 ■ PROJECT 6: REMOTE ED
- Page 508 and 509: CHAPTER 25 ■ PROJECT 6: REMOTE ED
- Page 510 and 511: CHAPTER 25 ■ PROJECT 6: REMOTE ED
- Page 512: CHAPTER 25 ■ PROJECT 6: REMOTE ED
- Page 515 and 516: 484 CHAPTER 26 ■ PROJECT 7: YOUR
- Page 517 and 518: 486 CHAPTER 26 ■ PROJECT 7: YOUR
- Page 519 and 520: 488 CHAPTER 26 ■ PROJECT 7: YOUR
- Page 521 and 522: 490 CHAPTER 26 ■ PROJECT 7: YOUR
- Page 523 and 524: 492 CHAPTER 26 ■ PROJECT 7: YOUR
- Page 525 and 526: 494 CHAPTER 26 ■ PROJECT 7: YOUR
- Page 527 and 528: 496 CHAPTER 26 ■ PROJECT 7: YOUR
- Page 529: 498 CHAPTER 26 ■ PROJECT 7: YOUR
- Page 533 and 534: 502 CHAPTER 27 ■ PROJECT 8: FILE
- Page 535 and 536: 504 CHAPTER 27 ■ PROJECT 8: FILE
- Page 537 and 538: 506 CHAPTER 27 ■ PROJECT 8: FILE
- Page 539 and 540: 508 CHAPTER 27 ■ PROJECT 8: FILE
- Page 541 and 542: 510 CHAPTER 27 ■ PROJECT 8: FILE
- Page 543 and 544: 512 CHAPTER 27 ■ PROJECT 8: FILE
- Page 545 and 546: 514 CHAPTER 27 ■ PROJECT 8: FILE
- Page 547 and 548: 516 CHAPTER 27 ■ PROJECT 8: FILE
- Page 549 and 550: 518 CHAPTER 28 ■ PROJECT 9: FILE
- Page 551 and 552: 520 CHAPTER 28 ■ PROJECT 9: FILE
- Page 553 and 554: 522 CHAPTER 28 ■ PROJECT 9: FILE
- Page 555 and 556: 524 CHAPTER 28 ■ PROJECT 9: FILE
- Page 558 and 559: CHAPTER 29 ■ ■ ■ Project 10:
- Page 560 and 561: CHAPTER 29 ■ PROJECT 10: DO-IT-YO
- Page 562 and 563: CHAPTER 29 ■ PROJECT 10: DO-IT-YO
- Page 564 and 565: CHAPTER 29 ■ PROJECT 10: DO-IT-YO
- Page 566 and 567: CHAPTER 29 ■ PROJECT 10: DO-IT-YO
- Page 568 and 569: CHAPTER 29 ■ PROJECT 10: DO-IT-YO
- Page 570 and 571: CHAPTER 29 ■ PROJECT 10: DO-IT-YO
- Page 572 and 573: CHAPTER 29 ■ PROJECT 10: DO-IT-YO
- Page 574 and 575: CHAPTER 29 ■ PROJECT 10: DO-IT-YO
- Page 576 and 577: CHAPTER 29 ■ PROJECT 10: DO-IT-YO
- Page 578 and 579: APPENDIX A ■ ■ ■ The Short Ve
500 CHAPTER 27 ■ PROJECT 8: FILE SHARING WITH XML-RPC<br />
Many issues are involved in constructing a peer-<strong>to</strong>-peer system—this project takes a very<br />
simple approach <strong>to</strong> things. In a system such as Gnutella, a peer may disseminate a query <strong>to</strong> all<br />
of its neighbors (the other peers it knows about), and they may subsequently disseminate the<br />
query further. Any peer that responds <strong>to</strong> the query can then send a reply through the chain of<br />
peers back <strong>to</strong> the initial one. The peers work individually and in parallel. (More recent systems,<br />
such as BitTorrent, use even more clever techniques, for example, requiring that you upload<br />
files in order <strong>to</strong> be allowed <strong>to</strong> download files.) To simplify things, your system will contact each<br />
neighbor in turn, waiting for its response before moving on. Not quite as efficient, but good<br />
enough for your purposes.<br />
Also, most peer-<strong>to</strong>-peer systems have clever ways of organizing their structure—that is,<br />
which peers are “next <strong>to</strong>” which—and how this structure evolves over time, as peers connect<br />
and disconnect. You’ll keep that very simple in this project, but leave things open for<br />
improvements.<br />
Specific Goals<br />
Here are some requirements that your program must satisfy:<br />
• Each node must keep track of a set of known nodes, from which it can ask for help. It<br />
must be possible for a node <strong>to</strong> introduce itself <strong>to</strong> another node (and thereby be included<br />
in this set).<br />
• It must be possible <strong>to</strong> ask a node for a file (by supplying a file name). If the node has the<br />
file in question, it should return it; otherwise it should ask each of its neighbors in turn<br />
for the same file (and they, in turn, may ask their neighbors). If any of these have the file,<br />
it is returned.<br />
• To avoid loops (A asking B, which in turn asks A) and <strong>to</strong> avoid overly long chains of<br />
neighbors asking neighbors (A asking B asking. . . asking Z), it must be possible <strong>to</strong> supply<br />
a his<strong>to</strong>ry when querying a node. This his<strong>to</strong>ry is just a list of which nodes have participated<br />
in the query up until this point. By not asking nodes already in the his<strong>to</strong>ry, you avoid<br />
loops, and by limiting the length of the his<strong>to</strong>ry, you avoid overly long query chains.<br />
• There must be some way of connecting <strong>to</strong> a node and identifying yourself as a trusted<br />
party. By doing so, you should be given access <strong>to</strong> functionality that is not available <strong>to</strong><br />
untrusted parties (such as other nodes in the peer-<strong>to</strong>-peer network). This functionality<br />
may include asking the node <strong>to</strong> download and s<strong>to</strong>re a file from the other peers in the<br />
network (through a query).<br />
• You must have some user interface that lets you connect <strong>to</strong> a node (as a trusted party)<br />
and make it download files. It should be easy <strong>to</strong> extend and, for that matter, replace this<br />
interface.<br />
All of this may seem a bit steep, but as you’ll see, implementing isn’t all that hard. And<br />
you’ll probably find that once you’ve got this in place, adding functionality of your own won’t<br />
be all that difficult either.