Docstoc

Ubiquity - A realtime Peer to Peer Communicator

Document Sample
Ubiquity - A realtime Peer to Peer Communicator Powered By Docstoc
					Ubiquity: Realtime P2P Communicator




 Ubiquity: A real time Peer to Peer Communicator


                          Saibal Kumar Ghosh
                   BT-Radianz | BT-13B | TechMahindra Limited




Page 1 of 22                                                    Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




                                   TABLE OF CONTENTS

1   Introduction................................................................................ 3
2   Intended Audience ...................................................................... 3
3   Technical Specifications .............................................................. 4
  3.1   Tools, IDE and Technologies Used ......................................... 4
  3.2 System Requirements ........................................................... 4
4 Goals ........................................................................................... 6
5 Peer to Peer versus a traditional Client - Server Network ............ 6
6 Architecture ................................................................................ 8
7 Ubiquity Communication Protocols............................................ 14
  7.1   Transmission Control Protocol ............................................ 14
  7.2 User Datagram Protocol ....................................................... 17
8 Walkthrough: Using Ubiquity ..................................................... 18
9 The Ubiquity Distributable and Features for the Future ............ 22
10    Bibliography .......................................................................... 22




Page 2 of 22                                                                Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




1 Introduction
Ubiquity is a real time Peer to Peer communicator built from the ground up on the
Microsoft .NET Framework 2.0.It supports reliable messaging over TCP/IP,
retransmission of messages on delivery failure, notification of fatal message delivery
failure and fast data transfers between peers. Ubiquity can run on any platform that is
capable of hosting the Microsoft .NET 2.0 Common Language Runtime.


2 Intended Audience
Developers, Team Leads and the general staff.




Page 3 of 22                                                        Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




3 Technical Specifications

3.1 Tools, IDE and Technologies Used
         Microsoft Visual Basic .NET 8.0
         Microsoft Visual Studio 2005 Team Edition for Software Developers
         Microsoft Network Monitor
         Windows Installer
         Microsoft ClickOnceTM deployment technology.



3.2 System Requirements
       Ubiquity is fully written in managed code and therefore requires the Microsoft .NET 2.0
Common Language Runtime to run. Ubiquity requires about 20 Megabytes of physical memory to
run but the Microsoft .NET framework 2.0 requires the following system configuration to be able
to run successfully.


Type                     Minimum                 Recommended             Comments

Processor                400 MHz                 800 MHz or above

Memory                   96 Mb (Client)          256 megabytes (Mb)
                         128 Mb (Server)         or above

Hard Disk Space          280 megabytes (Mb)      1 gigabyte (Gb)         32-bit version

Hard Disk Space          610 megabytes (Mb)      1 gigabyte (Gb)         64-bit version

Display                  800 x 600 256 colors    1024 x 768 High Color
                                                 (16-bit)


         Ubiquity can run on any platform which is capable of hosting the Microsoft .NET
Framework 2.0 CLR although it is not designed to run on Windows Mobile enabled smartphones.
Specific lists of Operating Systems are as follows:


x86 32-bit based systems
Microsoft Windows 98

Microsoft Windows 98 Second Edition

Microsoft Windows 2000 Professional with SP4

Microsoft Windows 2000 Server with SP4

Microsoft Windows 2000 Advanced Server with SP4




Page 4 of 22                                                             Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator


Microsoft Windows 2000 Datacenter Server with SP4

Microsoft Windows XP Professional with SP2

Microsoft Windows XP Home Edition with SP2

Microsoft Windows XP Media Center Edition 2002 with SP2

Microsoft Windows XP Media Center Edition 2004 with SP2

Microsoft Windows XP Media Center Edition 2005

Microsoft Windows XP Tablet PC Edition with SP2

Microsoft Windows XP Starter Edition

Microsoft Windows Millennium Edition

Microsoft Windows Server 2003 Standard Edition

Microsoft Windows Server 2003 Enterprise Edition

Microsoft Windows Server 2003 Datacenter Edition

Microsoft Windows Server 2003 Web Edition

x64-bit based systems
Microsoft Windows XP Professional x64 Edition

Microsoft Windows Server 2003, Standard x64 Edition

Microsoft Windows Server 2003, Enterprise x64 Edition

Microsoft Windows Server 2003, Datacenter x64 Edition

Itanium-based systems
Microsoft Windows Server 2003 with SP1, Enterprise Edition for Itanium-based Systems

Microsoft Windows Server 2003 with SP1, Datacenter Edition for Itanium-based Systems




                                                -




Page 5 of 22                                                         Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




4 Goals

The goals behind Ubiquity are as follows:

       To create a fully scalable communications architecture (number of users are limited only
        by the LAN capacity).
       To eliminate the need of a client server architecture (Peer to Peer).
       To support reliable message exchange amongst peers (Unicasting).
       To be able to send messages to all users in the network at once (Multicasting).
       Support for setting user availability mode.
       Support for a “Do Not Disturb” Mode.
       Support to block users.
       Support for encrypted message exchange.
       To support data transfers amongst peers to eliminate the need for setting up network.
        shares (Fast TCP/IP File Transfers).
       Support for archiving and printing of messages that has been exchanged amongst peers.
       Support for persisting user specific changes across sessions.



5 Peer to Peer versus a traditional Client - Server
  Network
     A Peer to Peer (henceforth referred to as P2P) network as the name implies is a decentralized
network where every computer connected to the network acts as a Server, as a client and often as
a router. A major difference between a traditional network and P2P is that there is no dedicated
server machine that keeps on listening to the network and to which other machines connect. Each
machine keeps a list of IP numbers of its nearest peers which is determined by the ping times. In
P2P terminology this is known as a Distributed Hash Table (DHT). This DHT spans multiple
computers on the network and as such this can grow to a very large volume.

         The diagram below shows the structure of Peer to Peer network architecture. Here we
have five terminals designated „A‟ through „E‟. From the figure its is clear that each terminal is
connected to its nearest neighbours. Internally they all maintain a list of IPs of their nearest
neighbours. Now if terminal „D‟ wants to communicate with „E‟ it can do so as there is a direct
connection between them. Other terminals need not be aware of them communicating. In fact
terminals „D‟ and „E‟ can keep on communicating even if all other links fail. This is because of the
fact that there is no central terminal to route the communications.

         Now let‟s consider terminal „A‟ wants to communicate with terminal „E‟. As is evident
from the diagram there is no direct connection between „A‟ and „E‟. But there are at least three
paths that exist between „A‟ and „E‟. We can designate them as „ABE‟, „ACE‟ and „ADE‟. Terminal
„A‟ can use any one of the paths to communicate with „E‟. In reality it would query each of the
terminals „B‟, „C‟ and „D‟ to know the ping times and thus the relative latency of the network path.
Since all of them are connected to „E‟ they would all respond with a time. Terminal „A‟ would then
choose the path with the least latency to communicate.




Page 6 of 22                                                                Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




        In general therefore if a terminal wants to connect to a particular terminal to which it is
not connected directly it would query its nearest neighbours to know if they are connected to the
destination terminal. If they are they would respond with a latency time. If they are not they
would forward the request to their nearest neighbours in turn to query the latency. Once the
sender terminal knows the path with the shortest times it would then proceed to send the
messages through that path. Since each terminal on the network might forward the request to
another terminal in case the destination terminal is not directly connected to them the sender
terminal might receive latency readings of paths even after it has started sending the packets. In
that case if it finds a better route it would modify the path on the next transmission.




Page 7 of 22                                                                Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




6 Architecture
A class level view of Ubiquity is as follows:




         Any communications software requires that a channel be setup between the
communicating parties. The sender generally becomes the server and the receiver, the client for
the duration of the session. Commercial chat software generally consists of a server which keeps
track of all the clients that are connected and all messages exchanged are routed through the
server. This is traditional client server architecture. In order to make Ubiquity truly Peer to Peer it
needed to be a server as well as a client at the same time thus eliminating the need for a server to
route the messages. The most important benefit from this architecture is the redundancy that is
introduced into the system. If the chat server goes down so does the whole network although the
clients maybe be in perfect condition for communication. Although commercial chat servers are
distributed and load balanced, the fact that all messages are routed through the server makes the
system vulnerable to failure.

         Ubiquity, in a true peer–to–peer fashion runs a dedicated thread that listens for user
requests. Once the handshaking is complete and a connection is established messages are
exchanged over the standard TCP/IP protocol. A detailed description of the message exchange
mechanism would follow later, but this mechanism should suffice to exhibit the fact that as long
as the two nodes are connected messages can be exchanged even if other nodes on the LAN fail.



Page 8 of 22                                                                 Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator



        A walkthrough of the major classes and modules of Ubiquity follows:




         This class contains fields for all the information about a particular peer. The most
important information about a particular user are the User Name, the User IP Address and the
User Status information. It also contains methods to enable the addition and removal of users
from the User List. The class is also designed to keep track of the ping times and the last heard
time for a particular user. This is to ensure that users who have been inactive can be removed and
their resources reclaimed if they have been silent for a specified amount of time.
         The File transfer class contains methods for the asynchronous transfer of files between
peers. It also contains methods to cancel the data transfer and notification of the concerned peers
in the event of a data transfer failure.




Page 9 of 22                                                               Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




Page 10 of 22                         Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




         This is the class that forms the broadcast chat window. It contains methods for
broadcasting messages on the network broadcast address. Messages sent to the broadcast address
can be received by all users running Ubiquity on that network.
         The IM class supports message exchange amongst peers, request for resending messages
in case of failure and notification of users in case of message delivery failure.




Page 11 of 22                                                          Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




Page 12 of 22                         Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




         This is a static module that forms the heart of Ubiquity. It contains methods to scan the
network for machines running Ubiquity, methods for the exchange of messages over TCP/IP,
signaling over UDP and data transfers amongst peers. A thread runs in the background that keeps
listening to incoming peer requests. Upon receipt of a request a connection is setup between the
peers and message and data transfer can be initiated.




Page 13 of 22                                                             Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




7 Ubiquity Communication Protocols
     Ubiquity currently supports IPv4 addressing and uses the two most commonly used
communication protocols: Transmission Control Protocol and User Datagram Protocol.




7.1 Transmission Control Protocol
      The Transmission Control Protocol (henceforth referred to as TCP) is used for the reliable
exchange of messages between peers. TCP requires the establishment of a session between the
two communicating parties which accounts for its reliability. Message exchange over TCP is
possible only when both the peers are online. The TCP packet structure is as follows

                                             TCP Header



             Bits
Bit offset            4–7                                8–15                         16–31
             0–3



    0                                      Source port                           Destination port



    32                                           Sequence number



    64                                       Acknowledgment number



             Data
    96              Reserved CWR ECE URG ACK PSH RST SYN FIN                      Window Size
             offset



   128                                     Checksum                              Urgent pointer



   160                                           Options (optional)




160/192+                                            Payload Data




A brief description of the various fields is as follows:




Page 14 of 22                                                            Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator


       Source port (16 bits) – identifies the sending port
       Destination port (16 bits) – identifies the receiving port
       Sequence number (32 bits) – has a dual role

               If the SYN flag is set, then this is the initial sequence number and the sequence
                number of the first data byte is this sequence number plus 1
               If the SYN flag is not set, then this is the sequence number of the first data byte

       Acknowledgement number (32 bits) – if the ACK flag is set then the value of this field is
        the next expected byte that the receiver is expecting.
       Data offset (4 bits) – specifies the size of the TCP header in 32-bit words. The minimum
        size header is 5 words and the maximum is 15 words thus giving the minimum size of 20
        bytes and maximum of 60 bytes. This field gets its name from the fact that it is also the
        offset from the start of the TCP packet to the data.
       Reserved (4 bits) – for future use and should be set to zero
       Flags (8 bits) (aka Control bits) – contains 8 1-bit flags

               CWR (1 bit) – Congestion Window Reduced (CWR) flag is set by the sending host
                to indicate that it received a TCP segment with the ECE flag set (added to header
                by RFC 3168).
               ECE (ECN-Echo) (1 bit) – indicate that the TCP peer is ECN capable during 3-
                way handshake (added to header by RFC 3168).
               URG (1 bit) – indicates that the URGent pointer field is significant
               ACK (1 bit) – indicates that the ACKnowledgment field is significant
               PSH (1 bit) – Push function
               RST (1 bit) – Reset the connection
               SYN (1 bit) – Synchronize sequence numbers
               FIN (1 bit) – No more data from sender

       Window (16 bits) – the size of the receive window, which specifies the number of bytes
        (beyond the sequence number in the acknowledgment field) that the receiver is currently
        willing to receive
       Checksum (16 bits) – The 16-bit checksum field is used for error-checking of the header
        and data
       Urgent pointer (16 bits) – if the URG flag is set, then this 16-bit field is an offset from the
        sequence number indicating the last urgent data byte
       Options (Variable bits) – the total length of the option field must be a multiple of a 32-bit
        word and the data offset field adjusted appropriately

               0 - End of options list
               1 - No operation (NOP, Padding)
               2 - Maximum segment size
               3 - Window scale
               4 - Selective Acknowledgement ok
               5-
               6-
               7-
               8 - Timestamp

    The last field is not a part of the header. The contents of this field are whatever the upper
layer protocol wants but this protocol is not set in the header and is presumed based on the port
selection.




Page 15 of 22                                                                 Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator


       Data (Variable bits): This is the payload, or data portion of a TCP packet. The payload
        may be any number of application layer protocols. The most common are HTTP, Telnet,
        SSH, FTP, but other popular protocols also use TCP.

The TCP State Diagram is as follows:




A very brief description of the various connection phases in TCP is as follows:

LISTEN
      Represents waiting for a connection request from any remote TCP and port. (usually set
      by TCP servers)

SYN-SENT
      Represents waiting for the remote TCP to send back a TCP packet with the SYN and ACK
      flags set.

SYN-RECEIVED
     Represents waiting for the remote TCP to send back an acknowledgment after having sent
     back a connection acknowledgment to the remote TCP. (usually set by TCP servers)

ESTABLISHED
     Represents the fact that the port is ready to receive/send data from/to the remote peer
     over TCP.




Page 16 of 22                                                              Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator


TIME-WAIT
     Represents waiting for enough time to pass to be sure the remote TCP received the
     acknowledgment of its connection termination request. According to RFC 793 a
     connection can stay in TIME-WAIT for a maximum of four minutes

TCP connections in Ubiquity are governed by the following three phases:

    1. connection establishment
    2. data transfer
    3. connection termination

A TCP connection in Ubiquity between two peers uses a three way handshake:

    1. The active open connection is established by the peer whishing to communicate sending a
       SYN to the destination peer.
    2. In response, the destination peer replies with a SYN-ACK.
    3. Finally the source peer sends an ACK back to the server.

     The source port and the destination port values are filled by Ubiquity during the transmission
of messages to the destination. The sequence number and the acknowledge number is used to
keep track of messages that were successfully delivered and those that weren‟t. The checksum bit
is used by the destination peer to check whether the data transmission was error free. At this
point, both the peers have received an acknowledgment of the connection and message exchange
can start between the peers.

7.2 User Datagram Protocol
          Ubiquity also supports broadcast messages which can be delivered to all peers on the
network. This entails the use of User Datagram Protocol (henceforth referred to as UDP) as a
means to deliver the message. UDP unlike TCP does not require the establishment of a session
between the peers and therefore can be used to send messages to all peers on the network even if
they are not online. Ubiquity also uses UDP as a means to exchange signaling information
between peers such as when a peer comes online or when a peer sets his/her status to „Away‟. The
source and destination fields are set by Ubiquity itself when the signaling message is transmitted.
The payload data contains the signaling information. The checksum is used by the destination
peer to compute whether the data was corrupted during transmission. The UDP packet structure
is as follows:


                        +          Bits 0 - 15                 16 – 31
                        0         Source Port              Destination Port
                       32            Length                  Checksum

                       64                           Data


A brief description of the various fields is as follows:

Source port
      This field identifies the sending port when meaningful and should be assumed to be the
      port to reply to if needed. If not used, then it should be zero.




Page 17 of 22                                                                 Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator


Destination port
      This field identifies the destination port and is required.

Length
         A 16-bit field that specifies the length in bytes of the entire datagram: header and data.
         The minimum length is 8 bytes since that's the length of the header. The field size sets a
         theoretical limit of 65,535 bytes (8 byte header + 65527 bytes of data) for a UDP
         datagram. The length includes the UDP header, so the minimum size for a UDP datagram
         is 8 (8 byte header with no data). The practical limit for the data length which is imposed
         by the underlying IPv4 protocol is 65,507 bytes.

Checksum
      The 16-bit checksum field is used for error-checking of the header and data.



8 Walkthrough: Using Ubiquity
      We consider two fictitious users using Ubiquity. Ubiquity runs by default in the background.
When the user screen is opened all the users currently running Ubiquity on that network are
listed. A chat session can be initiated by any user with another by double clicking on the user‟s
name on the list.




Page 18 of 22                                                              Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




         Once the handshaking is complete over TCP/IP a session is established between the two
peers and a new chat window opens for the exchange of chat messages between them. All
messages that are exchanged are encrypted end to end and cannot be read or modified by any
other peer other than the one for which it was meant. Ubiquity uses symmetric Rijndael algorithm
for the encryption of messages.




A peer can block another peer by adding his / her IP to the block list:




Page 19 of 22                                                             Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




        A peer can also set his status to away if he is busy to let other peers know about his
current status.




Doing so causes the user to show up differently on the user list:




Page 20 of 22                                                               Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




     A File Transfer request can be initiated from the options menu. Ubiquity uses TCP/IP for the
transfer of data between peers. The file transfer progress window is as shown below:




     Ubiquity is designed to transfer files as fast as possible. The actual data transfer speed is only
limited by the physical network capacity. Please note that the progress window displays the IP
addresses of the sender and receiver and as such has been grayed out.




Page 21 of 22                                                                Saibal Kumar Ghosh
Ubiquity: Realtime P2P Communicator




9 The Ubiquity Distributable and Features for the
  Future
                Ubiquity is always a work in progress. The latest version is always available at:
         http://www.saibal.org/stuff/ubiquity/install.aspx on the internet. Note that
         this is a all click once deployment version and might not work if you do not have
         administrative privileges on your local machines. Some specific additions and features
         to be incorporated into Ubiquity in the near future are:

                      Support for internetworking. Currently Ubiquity is only good for users in
                       the local LAN. Enabling this would ensure that users running Ubiquity
                       outside the local LAN can exchange messages and possibly even over the
                       internet.

                      Encryption of data exchanged between peers.

                      Folder transfers between peers.

                      “Send through Ubiquity” - Windows Context Menu




10 Bibliography

      Peer-to-peer Communication – Jiang Li (Microsoft Research)

      Peer-to-Peer Utility Maximization -Minghua Chen, Sudipta Sengupta, Miroslav
       Ponec, Philip A. Chou, and Jin Li (Microsoft Research)

      Proximity Neighbor Selection in Tree-Based Structured Peer-to-Peer
       Overlays - Miguel Castro, Peter Druschel, Y. Charlie Hu, Antony Rowstron (Microsoft
       Research)

      Peer to Peer Security – Dan S. Wallach (Rice University)

      RFC 793: Transmission Control Protocol
      RFC 1180: TCP/IP tutorial
      RFC 1323: TCP Extensions for High Performance
      RFC 768: User Datagram Protocol
      RFC 2508: Compressing IP/UDP/RTP Headers for Low-Speed Serial Links




                                     - End of Document --




Page 22 of 22                                                             Saibal Kumar Ghosh

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:25
posted:12/19/2011
language:English
pages:22