An Example Architecture for CS179i based on Gnutella and Python Yihua He

Sources  Gnutella Protocol v0.4  Norman Matloff’s “Introduction to Threads Programming with Python”  Gnutella Developer’s Forum (GDF)  Sources available online at  Trying to keep updated

Basic Components  A Gnutella Server Setup and maintain connection with neighbors Setup and maintain connection with neighbors Routing Pings/Pongs and Querys/QueryHits Routing Pings/Pongs and Querys/QueryHits A local searching mechanism A local searching mechanism  A Gnutella Client  Customized FTP/HTTP server and client for retrieving target files.

Data Structures – Neighbor Table  NeighborTable Fields: IP, TimeStamp Fields: IP, TimeStamp Keep track of current active neighbors. Neighbors are supposed to send pings periodically in order to keep themselves active. Timeout neighbors will be deleted from NeighborTable. Keep track of current active neighbors. Neighbors are supposed to send pings periodically in order to keep themselves active. Timeout neighbors will be deleted from NeighborTable.  RoutingHistory  FileSharingTable

Data Structures – Neighbor Table  NeighborTable Fields: IP, TimeStamp Fields: IP, TimeStamp Keep track of current active neighbors. Neighbors are supposed to send pings periodically in order to keep themselves active. Timeout neighbors will be deleted from NeighborTable. Keep track of current active neighbors. Neighbors are supposed to send pings periodically in order to keep themselves active. Timeout neighbors will be deleted from NeighborTable.  RoutingHistory  FileSharingTable

Data Structures –RoutingHistory  NeighborTable  RoutingHistory Fields: DescriptionID, MsgType, SourceIP, Timestamp Fields: DescriptionID, MsgType, SourceIP, Timestamp Pong/QueryHit descriptors may only be sent back along the same path that carried the orginal Ping/Query descriptors. Pong/QueryHit descriptors may only be sent back along the same path that carried the orginal Ping/Query descriptors. To limit the size of RoutingHistory Table, entries will be deleted after a certain period of time (timeout –Soft state) To limit the size of RoutingHistory Table, entries will be deleted after a certain period of time (timeout –Soft state)  FileSharingTable

Data Structures—FileSharing Table  NeighborTable  RoutingHistory  FileSharingTable Fields: FileID, FileName, FilePath, MetaDescription, FileSize, Date and so on Fields: FileID, FileName, FilePath, MetaDescription, FileSize, Date and so on Includes the files a node willing to share Includes the files a node willing to share In “QueryHit”, a node only sends out FileID to its peer. The peer opens a customized FTP/HTTP connection to the node and retrieve target files by FileID In “QueryHit”, a node only sends out FileID to its peer. The peer opens a customized FTP/HTTP connection to the node and retrieve target files by FileID

Main Loop Listen for new connection request “GNUTELLA CONNECT/0.4\n\n” If neighbor table full Spawn a new thread to handle connection Send “GNUTELLA NOT OK\n\n” Close connection Y N

Maintain and Routing Re-check if neighbor table full Put a new entry in NeighborTable Send “GNUTELLA OK\n\n” Send “GNUTELLA NOT OK\n\n” Close connection Thread ends Y N Listen for Description Head (23 bytes) At any stage, if it timeouts or any unexpected strings are received, the entry in NeighborTable will be deleted, connection will be closed and the thread ends Process descriptions accordingly: 1.Ping: Response with a Pong with node’s information. Update routing history table, TTL-=1 and forward Ping to all neighbors if TTL>0 2.Pong: Check with routing history table and if it is in, then TTL-=1 and forward to its destination; else discard 3.Query: Search local file (File Sharing Table), if hit, send Query/Hit with FileID and other info. Update routing history table, TTL-=1 and forward Query to all neighbors if TTL>0 4.QueryHit: Check with routing history table and if it is in, then TTL-=1 and forward to its destination; else discard