trout How To Build ADistributed Fis

trout How To Build A
Distributed Fish Tank.
Design Document For A Java-based Distributed Problem
Solver With The Graphical Interface Of A Fish Tank.


By Daniil Kurbatskiy, Natalya Meltser, Mark Schlowsky, and Adam Trachtenberg.



1.0 Introduction


Our problem is the creation a network consisting of nodes of a computation. These nodes move through the network to and from entities that accept and process these nodes. We have a graphical presentation for this problem. Fish serve as nodes, as they contain a part of the computation problem, and the fish tanks that accept them, allow these nodes to interact with the computers on the network. While these fish compute, some of the processor time will go to doing graphics instead of solving the problem.

The solution is a peer-to-peer network system that follows the principles of encapsulation, data hiding, and code reuse. Naturally, an object-oriented language is best suited for such a design. We chose to implement the design in Java, instead of C++ or SmallTalk, because of Java's cross-platform abilities combined with Remote Machine Instructions (RMI). Using RMI both makes communication across the network easier and preserves an object-oriented paradigm by allowing us to pass messages directly to objects across a network.

The design goals are to create a straight-forward object-oriented design that is reasonable to fully implement in two months. We also placed some criterion upon our design.

*The objects should have, for the most part, an intuitive behavior (a tank holds fish, a fish shipper receives fish, etc.)

*The system should be designed so it can still operate if multiple peers are taken off of the network unexpectedly.

*The design should also be reusable for different computations by just swapping a small number of components.

With the idea of a robust network in mind, the roles of the servers have been minimized. A server is still required to add a tank to the network as well as to keep track of the computation. However, without the server, the currently running and registered tanks will still be able to operate.

2.0 Overview


The networked fish tank can be viewed as three distinct high-level modules: the server, the fish shipper, and the actual fish themselves.

The server is a process running on a machine that serves two purposes. It handles registration of new fish shippers and sends out messages to have fish sent to the new shipper. It also directs the distributed computation carried out by the fish swimming in the network.

Each fish shipper runs on a different user's machine on a network. The shipper is responsible for directing the sending fish from one tank to another. So, there is a 1-1 correspondence between fish shippers and tanks. While a fish is responsible for shipping itself, it uses the fish shipper to do so. In general, a fish tells a fish shipper: "Scoop me out of your local tank and arrange for me to arrive at another fish shipper running on another machine. That new fish shipper should then place me in its personal tank."

The fish are what actually wanders through the network. They know how to draw themselves, have a message attached to them, and carry out a distributed computation. Also, each fish has behavior that governs when the fish will ship itself to another tank.

Many provisions have been made so that the network of shippers will not be brought down by any reasonable number of machines being removed from the network, be it from crashing or some other reason, including the server. The network is organized as a web with edges connecting shippers constantly changing. This is in contrast to a token ring, which could not recover as easily from multiple machines being removed unexpectedly.

2.1 Network Organization


We must ensure that new users can be added to the network and find out about other fish tanks while still maintaining a robust and decentralized network. To do so, we place the server as the entryway to the network. When a new shipper registers with the server, it instructs existing fish shippers to send the new shipper some fish to fill the tank. When the new fish arrive, the shippers will derive information about the location of other shippers from the fish. It will then add these locations to a list containing its most recent shippers. Fish will send themselves out to different shippers on that list. Because of this cross-pollination, the network should resemble a web instead of a token loop. The only times the fish will have to contact the server is to get a piece of the computation and when their section of the computation is done.

2.2 Communication


All communication between objects across the network is carried out by objects using RMI. This reduces the amount of coding required for communications across the network while keeping an object oriented design. While RMI is slow, it is reliable, which is much more important for our purposes.

2.3 Advantages


There are several advantages to this design, the most important is that the system will be able to function with multiple machine or network failures. While no shippers can be able to be added if the tank server crashes, the shippers already running can continue to operate. If the fish server crashes, no fish will be given a part of the computation to do nor will a fish be able to report back the results of its computation; however, the fish will still be able to be created and swim between tanks.

The division between the communication classes, the graphics classes, and the calculation methods make developing the system much easier. Do-nothing code modules can be substituted during development and then, as classes become available, they are substituted in.

2.4 Disadvantages


The major problem is the dependence between the Fish and FishShipper. This was necessary to allow the fish to have more control over its own behavior, while not setting up an extensive callback system. Testing the system without the basic components of at least the FishTank, FishList, FirstFish, NullFish, Fish, and a specific fish is very difficult.

Implementing the system involves a thorough understanding of threads and synchronization problems, but it is inherent in this type of system.

3.0 Modules


The modules section describes the projects in lower-level terms than the Overview section. Therefore, it breaks the above-mentioned Server, Fish Shipper, and Fish into smaller pieces.

3.1 Servers


This module is responsible for getting a tank up on the network and for keeping track of the computation. This module is split into two sub-modules, the tank server and the fish server, that are different processes running on possibly two different machines.

The tank server is responsible for telling some tanks already existing on the network that a new tank has been added and that those veteran tanks need to send fish to the new tank. The tank server will periodically write tanks locations to disk, so that if it crashes and is restarted, it does not lose all of its data.

The fish server keeps track of the computation. This server portions out parts of the computation to fish and puts all the parts together when it receives the results. Each fish will contact the server when it is created to get a piece of the computation, then it will contact the server again when the computation is done. The server will need to notify whomever is supervising the computation when a solution is found or when the search space is exhausted.

3.1.1 Tank Server


Responsibilities

Registering a tank
Having fish sent to the new tank
Keeping track of the number of tanks it knows about.

Events

Creation: Initialize all necessary data structures
Receive a registration: Contact other tanks and have them send fish to the new tank and add the new tank to its bag of known tanks. If it the first tank to register, record the tank location.

3.1.2 Fish Server


Responsibilities

Dividing up the calculation
Giving out parts of the calculation to the fish
Putting the parts of the computation back together
Keeping track of what parts have been given out and/or received back
Notify someone when the calculation is done

Events

Creation: Divide up the computation
Receive a request for a part: give out a part of the computation and record it
Receive a finished part: mark that part as finished and process it accordingly
Computation is completed: Output to the screen or send email to indicate that it is done. All subsequent requests for parts will be respond with an indicator that the computation is done.

3.2 TankLocationBag


This module is an abstraction of having an unordered bag containing the locations of other tanks. The location itself, in reality an URL, is represented as a string.

The bag module has certain properties. It can only hold a specific number of locations. When it is full, the oldest tank locations are thrown away first. There is a method to get a random location from the bag, as well as to remove a specific location from the bag. There is also method to add a location to the bag if it is not already in there and there is a method to compare two bags and add the locations that are not already in the bag "foo" to bag "bar."

This set of modules abstracts the idea of a bag of locations that can easily be transferred to tanks and fish.

Responsibilities

Keeping a length bounded list of tank locations (strings)
Adding new location
Removing old location to make room for new ones.
Returning a random location

Events

Creation: is told the number of tank locations it can hold and initialize necessary data structures
Add a location
Add all unknown locations from another bag
Get a random location

3.3 Tank


The tank is responsible for drawing itself on the screen and managing the list of fish in its tank. It has a list head and forwards messages from the fish shipper (such as, sending a

Kết quả (Việt) 1:

cá hồi làm thế nào để xây dựng ABể cá phân phối.Thiết kế tài liệu cho một vấn đề phân phối dựa trên JavaNgười giải quyết với giao diện đồ họa của một bể cá.Bởi Daniil Kurbatskiy, Natalya Meltser, Mark Schlowsky, và Adam Trachtenberg. 1.0 introduction Vấn đề của chúng tôi là việc tạo ra một mạng lưới bao gồm các nút của một tính toán. Các nút di chuyển thông qua mạng lưới đến và đi từ thực thể đó chấp nhận và xử lý các nút. Chúng tôi có một bài thuyết trình đồ họa cho vấn đề này. Cá phục vụ như nút, vì chúng chứa một phần của vấn đề tính toán, và các thùng nhiên liệu cá mà chấp nhận chúng, cho phép các nút để tương tác với các máy tính trên mạng. Trong khi những con cá tính, một số thời gian xử lý sẽ đi làm đồ họa thay vì giải quyết vấn đề.Giải pháp là một hệ thống peer-to-peer mạng sau các nguyên tắc của đóng gói, dữ liệu ẩn và sử dụng lại mã. Đương nhiên, một đối tượng theo định hướng ngôn ngữ là thích hợp nhất cho một thiết kế. Chúng tôi đã chọn để thực hiện thiết kế trong Java, thay vì C++ hoặc SmallTalk, bởi vì khả năng cross-nền tảng Java kết hợp với hướng dẫn máy từ xa (RMI). Sử dụng RMI cả làm cho giao tiếp trên mạng dễ dàng hơn và bảo tồn một mô hình hướng đối tượng bằng cách cho phép chúng tôi để vượt qua tin nhắn trực tiếp cho các đối tượng qua mạng.Mục tiêu thiết kế là để tạo ra một thiết kế về phía trước thẳng hướng đối tượng đó là hợp lý để thực hiện đầy đủ trong hai tháng. Chúng tôi cũng đặt một số tiêu chí theo thiết kế của chúng tôi. * Các đối tượng cần phải có, hầu hết các phần, một hành vi trực quan (một chiếc xe tăng giữ cá, một người gửi cá nhận được cá, v.v..) * Hệ thống nên được thiết kế để nó có thể vẫn hoạt động nếu nhiều đồng nghiệp được lấy giảm giá của mạng bất ngờ. * Thiết kế nên cũng được tái sử dụng cho tính toán khác nhau bằng cách thay đổi chỉ một số ít các thành phần. Với ý tưởng của một mạng lưới mạnh mẽ trong tâm trí, vai trò của các máy chủ đã được giảm thiểu. Một máy chủ là vẫn còn cần thiết để thêm một chiếc xe tăng vào mạng cũng như để theo dõi các tính toán. Tuy nhiên, mà không có máy chủ, các thùng nhiên liệu hiện đang chạy và đăng ký vẫn sẽ có thể hoạt động.2.0 Tổng quan về Bể cá nối mạng có thể được xem như là ba module khác biệt cao cấp: hệ phục vụ, người gửi cá và các loài cá thực tế bản thân.Các máy chủ là một tiến trình đang chạy trên một máy phục vụ hai mục đích. Nó xử lý các đăng ký mới cá chủ hàng và gửi các tin nhắn có cá được gửi đến người gửi mới. Nó cũng chỉ đạo tính toán phân phối thực hiện bởi các cá bơi trong mạng.Mỗi người gửi cá chạy trên máy tính của người dùng khác trên mạng. Người nhập chịu trách nhiệm chỉ đạo các cá gửi từ một xe tăng khác. Vì vậy, có là một 1-1 thư giữa cá chủ hàng và xe tăng. Trong khi một cá chịu trách nhiệm vận chuyển chính nó, nó sử dụng người gửi hàng cá để làm như vậy. Nói chung, một cá cho cá một người gửi: "Scoop tôi ra khỏi xe tăng địa phương của bạn và sắp xếp cho tôi để đi đến một người gửi cá chạy trên một máy tính. Rằng người gửi cá mới nên sau đó đặt tôi trong bể cá nhân của nó."Cá là những gì thực sự đi lang thang qua mạng. Họ biết làm thế nào để vẽ bản thân mình, có một tin nhắn gắn liền với chúng, và thực hiện một tính toán phân phối. Ngoài ra, mỗi cá có hành vi điều chỉnh việc khi cá sẽ xuất xưởng chính nó để xe tăng khác.Nhiều quy định đã được thực hiện để mạng lưới các chủ hàng sẽ không được đưa bởi bất kỳ số lượng máy đang được gỡ bỏ từ mạng, hợp lý là nó bị rơi hoặc một số lý do khác, bao gồm cả máy chủ. Mạng được tổ chức như là một trang web với cạnh kết nối chủ hàng thay đổi liên tục. Điều này là trái ngược với một vòng mã thông báo, mà có thể không khôi phục dễ dàng từ nhiều máy tính đang được gỡ bỏ bất ngờ.2.1 tổ chức mạng Chúng ta phải đảm bảo rằng người dùng mới có thể được thêm vào mạng và tìm hiểu về xe tăng cá khác trong khi vẫn duy trì một mạng lưới mạnh mẽ và phân cấp. Để làm như vậy, chúng tôi đặt hệ phục vụ như là lối vào mạng. Khi một người gửi mới đăng ký với máy chủ, nó hướng dẫn sẵn có chủ hàng cá để gửi người nhập mới một số loài cá để điền vào các bồn chứa. Khi cá mới đến, các chủ hàng sẽ lấy được thông tin về vị trí của chủ hàng khác từ cá. Nó sau đó sẽ thêm các địa điểm này vào một danh sách có chứa các chủ hàng đặt. Cá sẽ gửi mình cho các chủ hàng khác nhau trên danh sách đó. Vì thụ phấn chéo này, mạng nên trông giống như một trang web thay vì một vòng lặp token. Chỉ lần cá sẽ có liên hệ với hệ phục vụ là để có được một mảnh của tính toán và khi phần của họ trong tính toán được thực hiện.2.2 truyền thông Tất cả thông tin liên lạc giữa các đối tượng trên toàn bộ mạng được thực hiện bởi các đối tượng bằng cách sử dụng RMI. Điều này làm giảm số lượng mã hóa cần thiết cho truyền thông qua mạng trong khi giữ cho một đối tượng theo định hướng thiết kế. Trong khi RMI là chậm, nó là đáng tin cậy, mà là rất quan trọng cho các mục đích của chúng tôi.2.3 lợi thế Có một số lợi thế để thiết kế này, quan trọng nhất là hệ thống sẽ có thể hoạt động với nhiều thất bại máy hoặc mạng. Trong khi chủ hàng không có thể có thể được thêm nếu máy chủ xe tăng đổ vỡ crash, chủ hàng đang chạy có thể tiếp tục hoạt động. Nếu các máy chủ cá treo, cá không sẽ được trao một phần của tính toán để làm, cũng không một cá sẽ có thể báo cáo trở lại kết quả tính toán của nó; Tuy nhiên, cá sẽ vẫn có thể là tạo ra và bơi giữa xe tăng.Sự phân chia giữa các lớp học truyền thông, các lớp học đồ họa và các phương pháp tính toán thực hiện phát triển hệ thống dễ dàng hơn nhiều. Mô-đun chuyển mã có thể được thay thế trong quá trình phát triển và sau đó, như các lớp học trở nên có sẵn, họ được thay thế trong.2.4 bất lợi Vấn đề chính là sự phụ thuộc giữa cá và FishShipper. Điều này là cần thiết để cho phép các cá để có thêm quyền kiểm soát hành vi của riêng của nó, trong khi không thiết lập một hệ thống rộng lớn gọi lại. Thử nghiệm hệ thống mà không cần các thành phần cơ bản của ít nhất là FishTank, FishList, FirstFish, NullFish, cá và cá cụ thể là rất khó khăn.Thực hiện hệ thống liên quan đến một sự hiểu biết toàn diện về chủ đề và các vấn đề đồng bộ hóa, nhưng nó là cố hữu trong loại của hệ thống.3.0 mô-đun Mô-đun phần mô tả các dự án về cấp thấp hơn so với phần tổng quan. Do đó, nó phá vỡ nói trên máy chủ, người gửi cá, và cá thành từng miếng nhỏ.3.1 máy chủ Mô-đun này chịu trách nhiệm để có được một chiếc xe tăng lên trên mạng và theo dõi các tính toán. Mô-đun này được chia thành hai mô-đun phụ, máy chủ xe tăng và phục vụ cá mà là khác nhau quá trình chạy trên có thể có hai máy khác nhau.Máy chủ xe tăng chịu trách nhiệm cho một số xe tăng đã tồn tại trên mạng một loại xe tăng mới đã được thêm vào và những thùng cựu chiến binh phải gửi cá cho loại xe tăng mới. Máy chủ xe tăng sẽ định kỳ viết xe tăng vị trí vào đĩa, do đó nếu nó treo và khởi động lại, nó không mất tất cả dữ liệu của nó.Các máy chủ cá theo dõi các tính toán. Hệ phục vụ này phần trong phần của tính toán để cá và đặt tất cả các phần với nhau khi nó nhận được kết quả. Mỗi cá sẽ liên lạc với hệ phục vụ khi nó được tạo ra để có được một mảnh tính toán, sau đó nó sẽ liên lạc với hệ phục vụ một lần nữa khi tính toán được thực hiện. Các máy chủ sẽ cần phải thông báo cho bất cứ ai giám sát những tính toán khi một giải pháp được tìm thấy hoặc khi không gian tìm kiếm bị cạn kiệt.3.1.1 tank Server Trách nhiệm Đăng ký một chiếc xe tăng Có cá cho loại xe tăng mới Theo dõi các số lượng xe tăng nó biết về. Sự kiện Sáng tạo: Khởi tạo tất cả các cấu trúc dữ liệu cần thiết Nhận được một đăng ký: liên hệ với các xe tăng và họ có gửi cá cho loại xe tăng mới và thêm loại xe tăng mới vào túi xe tăng được biết đến. Nếu nó tăng đầu tiên để đăng ký, ghi lại vị trí xe tăng. 3.1.2 cá Server Trách nhiệm Chia ra tính toán Đưa ra một phần của tính toán cho cá Đưa các phần của tính toán trở lại với nhau Theo dõi của những phần nào đã được đưa ra và/hoặc nhận được trở lại Thông báo cho một người nào đó khi tính toán được thực hiện Sự kiện Sáng tạo: Chia lên những tính toán Nhận được yêu cầu cho một phần: cung cấp cho ra một phần của tính toán và ghi lại nó Nhận được một phần hoàn thành: đánh dấu phần đó khi kết thúc và xử lý nó cho phù hợp Tính toán đã được hoàn thành: đầu ra màn hình hoặc gửi email để chỉ ra rằng nó được thực hiện. Tất cả các yêu cầu cho các bộ phận sẽ là đáp ứng với một chỉ số tính toán được thực hiện. 3.2 TankLocationBag Mô-đun này là một trừu tượng của việc có một túi có thứ tự chứa các vị trí của xe tăng khác. Vị trí chính nó, trong thực tế một URL, được thể hiện như một chuỗi.Các mô-đun túi có thuộc tính nhất định. Nó chỉ có thể chứa một số địa điểm cụ thể. Khi nó được đầy đủ, địa điểm xe tăng lâu đời nhất được ném đi đầu tiên. Đó là một phương pháp để có được một vị trí ngẫu nhiên từ túi, cũng như để loại bỏ vị trí cụ thể từ các túi. Đó cũng là phương pháp để thêm vị trí vào túi nếu nó không phải là đã có và có là một phương pháp để so sánh hai túi và thêm các vị trí có không đã trong túi "foo" túi "thanh."Này tập hợp các mô-đun abstracts ý tưởng của một túi địa điểm có thể dễ dàng được chuyển giao cho xe tăng và cá.Trách nhiệm Giữ một chiều dài bao bọc danh sách địa điểm xe tăng (chuỗi) Thêm vị trí mới Loại bỏ vị trí cũ để nhường chỗ cho những cái mới. Trở về vị trí ngẫu nhiên Sự kiện Sáng tạo: nói với số địa điểm xe tăng nó có thể giữ và khởi tạo cấu trúc dữ liệu cần thiết Thêm vị trí Thêm tất cả các vị trí không xác định từ một túi Có được một vị trí ngẫu nhiên 3.3 xe tăng Chiếc xe tăng là chịu trách nhiệm cho bản vẽ chính nó trên màn hình và quản lý danh sách các cá trong bể của nó. Nó có đầu danh sách và chuyển tiếp các thư từ người gửi cá (chẳng hạn như, gửi một