1. CSE333 CSE333 DDS.1 A System for Creating Specialized DDS Architectures Research and Work By: Tom Puzak Nathan Viniconis Solomon Berhe Jeffrey Peck Project web site: http://www.revrick.net/CSE333/ProjectTimeline.htm

2. CSE333 CSE333 DDS.2Objectives  Break down multiple (Data Distribution System) DDS architectures into their main components.  Create a unified view of the differing architectures in UML.  Tag elements in each component with the attributes of each DDS analyzed.  Propose a method to generate DDS architectures by utilizing the component breakdown and attribute selection.

3. CSE333 CSE333 DDS.3Process  Step 1: Pick a subset of existing DDSs  Step 2: Determine main common components  Step 3: Break up the components within each DDS into disjoint entities.  Step 4: Combine the breakdowns of the different DDSs together within each component  Step 5: Determine a set of attributes, and tag inheritance lines with them  Step 6: Create an architecture based on a set of given attributes in which to customize  Step 7: Analysis, Conclusions, Problem summary, and more

4. CSE333 CSE333 DDS.4 Step 1: Pick a subset of existing DDSs  DDSs are used to transfer data across a network, however the methods involved vary.  To generate a more complete picture of the generic DDS architecture, analysis of existing DDSs needs to take place over a broad scope.  We chose four DDSs:  Unix FTP – FTP Protocol  Limewire – Gnutella Protocol  BitTorrent – BitTorrent Protocol  DC++ – Direct Connect Protocol (not standard)  They are all File Sharing Applications but their underlying functionality is different.

5. CSE333 CSE333 DDS.5 Step 1: Pick a subset of existing DDSs The DDSs were chosen to show a wide range of functionality:  FTP was chosen because of its simplicity  Sever and client have separate, well-defined roles  Maintains separate connections for data and messages (i.e. commands)  Lots of documentation available  Limewire represents an interesting and very popular peer-to-peer system  No central server; every client is also a server  Every client maintains network  Searches traverse the network to a defined depth

6. CSE333 CSE333 DDS.6 Step 1: Pick a subset of existing DDSs  BitTorrent was chosen because it is exotic.  It does not behave like any other peer-to-peer file sharing system.  Very large files are broken into small pieces which are “held together” by.torrent files, which contain information about the files.  A new solution to the problem of transferring large files over the Internet  Direct Connect was chosen because it represents a simple peer-to-peer system that utilizes it's own non-standard protocol.  Clients connect to a hub, where they search for other client's files and then directly connect.  Maintains security, restricting certain functions on the hub from non-“Op” users.

7. CSE333 CSE333 DDS.7Process  Step 1: Pick a subset of existing DDSs  Step 2: Determine main common components  Step 3: Break up the components within each DDS into disjoint entities.  Step 4: Combine the breakdowns of the different DDSs together within each component  Step 5: Determine a set of attributes, and tag inheritance lines with them  Step 6: Create an architecture based on a set of given attributes in which to customize  Step 7: Analysis, Conclusions, Problem summary, and more

8. CSE333 CSE333 DDS.8 Step 2: Determine main common components FTP Limewire DirectConnect BitTorrent 1.Network Connection 2.Search 3.Different Security Mechanism 4.GUI

9. CSE333 CSE333 DDS.9 Step 2: Determine main common components  Initial focus of research is the Network Communication  Communication between peers  Commucication between host and server  Responsible for sending/receiving msg/files  Responsible for searching mechanism

10. CSE333 CSE333 DDS.10Process  Step 1: Pick a subset of existing DDSs  Step 2: Determine main common components  Step 3: Break up the components within each DDS into disjoint entities.  Step 4: Combine the breakdowns of the different DDSs together within each component  Step 5: Determine a set of attributes, and tag inheritance lines with them  Step 6: Create an architecture based on a set of given attributes in which to customize  Step 7: Analysis, Conclusions, Problem summary, and more

11. CSE333 CSE333 DDS.11 Step 3: Break up the components within each DDS into disjoint entities.  Sources  Use Papers  Open APIs  Problems  Within one DDSs components overlap significantly  Searching relies on the network communication  Security is wrapped into everything  Solutions  Strip away functionality which is overlapping  This creates a generic and an application specific layer

12. CSE333 CSE333 DDS.12 Step 3: Break up the components within each DDS into disjoint entities. Network Communication Search Network Communication

13. CSE333 CSE333 DDS.13Process  Step 1: Pick a subset of existing DDSs  Step 2: Determine main common components  Step 3: Break up the components within each DDS into disjoint entities.  Step 4: Combine the breakdowns of the different DDSs together within each component  Step 5: Determine a set of attributes, and tag inheritance lines with them  Step 6: Create an architecture based on a set of given attributes in which to customize  Step 7: Analysis, Conclusions, Problem summary, and more

14. CSE333 CSE333 DDS.14 Step 4: Combine the breakdowns of the different DDSs together within each component  A global component is created that is a superset of all generic architectures from every DDS.  After all generic layer for all DDSs have been found the architectures are added together to create a larger one.  Find generic layer for each DDS.  Add the resulting architectures together to create a larger one.

15. CSE333 CSE333 DDS.15 Step 4: Combine the breakdowns of the different DDSs together within each component

16. CSE333 CSE333 DDS.16Process  Step 1: Pick a subset of existing DDSs  Step 2: Determine main common components  Step 3: Break up the components within each DDS into disjoint entities.  Step 4: Combine the breakdowns of the different DDSs together within each component  Step 5: Determine a set of attributes, and tag inheritance lines with them  Step 6: Create an architecture based on a set of given attributes in which to customize  Step 7: Analysis, Conclusions, Problem summary, and more

17. CSE333 CSE333 DDS.17 Step 5: Determine a set of attributes, and tag inheritance lines with them  Each component has been broken up into a generic and application layer. The generic layers’ components are inherited by each DDS.The generic layers’ components are inherited by each DDS. Attribute sets for each inheritance through the generic layer will be found.Attribute sets for each inheritance through the generic layer will be found.

18. CSE333 CSE333 DDS.18 Step 5: Determine a set of attributes, and tag inheritance lines with them  The attribute sets pertaining to each inheritance line have to be carefully chosen.  These will be the base of a new DDS architecture.  Some examples of the possible attributes that may be used can be seen through the search example.  Generic Layer  FTP Layer  Search over Telnet  FTP language  Use file/directory structure search  Generic Layer  BitTorrent  Search over HTTP  Query DB of file locations  Return connection information for file host  Generic Layer  Limewire  Deep search through network traversal  Utilize caching  Limit depth searched

19. CSE333 CSE333 DDS.19Process  Step 1: Pick a subset of existing DDSs  Step 2: Determine main common components  Step 3: Break up the components within each DDS into disjoint entities.  Step 4: Combine the breakdowns of the different DDSs together within each component  Step 5: Determine a set of attributes, and tag inheritance lines with them  Step 6: Create an architecture based on a set of given attributes in which to customize  Step 7: Analysis, Conclusions, Problem summary, and more

20. CSE333 CSE333 DDS.20 Step 6: Create an architecture based on a set of given attributes in which to customize  Sets of attributes have now been given to the inheritances through the generic layer within each component.  The user will be able to view the different sets of attributes available for each component.  Next, the user selects the best-fit attribute set for each component.  The application layer component of each chosen attribute set is returned and is displayed to the user. As a result:  As more DDSs are analyzed and added to this system, the number of possible outcomes rapidly grows.

21. CSE333 CSE333 DDS.21Process  Step 1: Pick a subset of existing DDSs  Step 2: Determine main common components  Step 3: Break up the components within each DDS into disjoint entities.  Step 4: Combine the breakdowns of the different DDSs together within each component  Step 5: Determine a set of attributes, and tag inheritance lines with them  Step 6: Create an architecture based on a set of given attributes in which to customize  Step 7: Analysis, Conclusions, Problem summary, and more

22. CSE333 CSE333 DDS.22 Step 7: Analysis, Conclusions, Problem summary, and more For this final step, we plan on analyzing our work:  Any difficulties encountered will be discussed.  Could we have taken measures to avoid problems?  We will make conclusions:  Did we successfully create an architecture by which a new DDS could be spawned?  Is our architecture thorough?  Is our theoretical model able to work in reality?  Could the use of our architecture benefit a DDS creator by saving time, money, or both?

23. CSE333 CSE333 DDS.23 Step 7: Analysis, Conclusions, Problem summary, and more  We will analyze our UML structure:  Did we use the proper diagrams to express the ideas behind our research?  Was UML able to accurately simulate our theoretical model?  Would our final UML model able to clearly demonstrate our generic DDS architecture to somebody who is outside the project?  A novel idea is tagging the inheritance found in UML with attributes that describe the specific gains of the class.

24. CSE333 CSE333 DDS.24 Individual Focus  Each group member took a different DDS to break down and analyze.  Solomon Berhe: Limewire  Jeff Peck: DC++  Tom Puzak: FTP  Nate Viniconis: BitTorrent  The responsibilities include:  Creating an overview UML class diagram describing the workings of the application  Breaking the UML diagram into the main components  Proposing a generic layer for each main component contained within.

25. CSE333 CSE333 DDS.25 Original Project Focus  Analyze existing DDSs and break them down into their “functional components”  Combine the UML diagrams of the each component together into a global component  Tag different areas of each global components with attributes  Develop a set of hueristics for generating a customized DDS using:  user selected attributes  global version of each component

26. CSE333 CSE333 DDS.26 Current Progress  Identified some major DDS components  Defined generic root of the “Network Communication” tree  Began creation of UML class diagrams. FTP Ex:

27. CSE333 CSE333 DDS.27 Planned Future Activities  Finalize list of common components  Diagram components with UML  Discretize overlapping components in UML diagrams  Break down components into their most generic pieces  Develop unified view of broken down components  Inheritence hierarchy

28. CSE333 CSE333 DDS.28 Future Activities (Continued)  Describe inheritence in terms of attributes  Propose method for creating customized DDS architectures based on attributes  Analyze the performance the architecture engine

29. CSE333 CSE333 DDS.29 References (1)

30. CSE333 CSE333 DDS.30 References (2)