wiki:GENIExperimenterWelcome/Repository/Seattle

Version 1 (modified by Mark Berman, 12 years ago) (diff)

--

Seattle Example Experiments

Seattle is a sister testbed of GENI. Seattle provides access to a large universe of diverse computing devices (e.g. shared-use desktop, laptop, tablets, and phones), displaying realistic network diversity (wired, wireless, intermittent connectivity, mobility), all via an easy to use programming language.

Some example experiments build upon Seattle are listed below.

NAT Traversal / Non-transitive connectivity Seattle logo The purpose of this assignment is to illustrate several important networking concepts by measuring the connectivity between computers spread around the Internet. For this task we will be using Seattle, and in the first part of this assignment you will familiarize yourself with the Seattle demokit. Once you are comfortable with the demokit, we will run an all-pairs-ping on computers distributed around the world. The goal of running the all-pairs-ping is to observe non-transitive connectivity (when two computers cannot communicate, but they can both communicate with a third computer). Following this, we will set up one-hop detour routing to circumvent non-transitive connectivity to allow the computers to communicate through the intermediate node. The final part of the assignment investigates whether or not a computer is behind a NAT (network address translator) and illustrates the practical issues with communicating with a NATed node.
Stop And Wait Protocol Seattle logo In this assignment, you will implement a reliable datagram protocol using the stop-and-wait (also known as alternating bit) protocol. You will write client and server programs that communicate using your library. The server will listen for messages and send back acknowledgements. The client will send messages and listen for acknowledgements. The client will consider a message delivered once it receives an acknowledgment and resend an unacknowledged message after a timeout. After a finite number of resent messages, the client will give up and report an error.
Sliding Window Protocol Seattle logo In this assignment, you will extend the Stop and Wait Assignment with the sliding window algorithm. The purpose of this algorithm is to enable the sender to use the available network bandwidth more efficiently. This is achieved by sending more than one packet at a time before waiting to receive acknowledgements. This pipelining of packets makes for a much higher bandwidth communication protocol than the previous Stop And Wait Protocol.
Link State Routing (Dijkstra's Algorithm) Seattle logo This assignment will illustrate an important network routing strategy called Link State routing. In this assignment, Seattle nodes will take an initial connectivity map of nodes. They will then implement and run Dijkstra's shortest path algorithm to build their routing tables. Finally, nodes will forward packets using their routing table.
HTTP Server Assignment Seattle logo In this part of the project you will create a minimal web server to serve text and html files. Your webserver will have a single dynamic component for listing files in a directory, it will need to read and send file contents to clients as well as accept incoming data.
Chat Server Assignment Seattle logo This assignment focuses on designing and implementing a chat service called Seattlechat. Seattlechat has three main components, a central Seattlechat server whose focus is to relay messages, a collection of Seattlechat translators that change messages into different formats for display, and a Seattlechat client which is will use a standard web browser for communicating with a user. Each Seattlechat client has its own translator, but many translators can connect to the same Seattlechat server.
DHT Assignment (Chord) Seattle logo For this assignment the students first implement a DHT-like message routing system based on Chord, and test their implementations on local Seattle resources. The students then run their code on globally distributed Seattle resources. Chord works well over LAN, but has performance and correctness problems in a global scale deployment with non-transitive connectivity. After explaining the reasons behind Chord's poor performance, the instructor can have the class discuss solutions to these problems. Students can then implement these solutions to achieve better performance and reliability.

Attachments (1)

Download all attachments as: .zip