1. P2P Project Mark Kurman Nir Zur Danny Avigdor

2. Introduction ► Motivation:  Firewalls may allow TCP or UDP connections on several specific ports and block traffic that uses different ones.  This may result in failure to create communication between two peers. ► Our solution:  We will use ports that are commonly left open by firewalls.  Port 80 for http is a good example.  A "manager" that communicates on that port will “manage” Traffic that can't go directly from one peer to the other.  we would like to use the "manager" as a bridge point as little as possible. In case the communication can be done directly from one peer to the other it will do so.

3. General layout peer FW network Manager peer

4. Basic Flow ► Manager starts up and listens on port 80 for incoming messages. ► Client Sign In  Client sign in. each Client will have a unique ID (the clients username) to enable support of dynamic IP addresses and multiple clients from the same host.

5. SignIn scenarios Client Sign In Ack + Update Manager Check for legal ID and Insert Client to DB new client Client Sign In Ack + Update Manager Check for legal ID and change status in DB reSignIn

6. SignIn scenarios (2) Client Sign In Manager Check for legal ID and send Error message Existing ID Error message Client Sign In Manager Manager offline Display error message Display time out message Time Out

7. New session Client A wants to speak to client B ► A contacts Manager and asks for a session with B. ► In case B is not signed in, Manager notifies A. ► In case B is signed in, the Manager informs A of B’s IP address. A tries to connect B using UDP and TCP at the same time – the first to succeed will be taken (this way, in case of failure, we wait only one time-out). ► If A fails to connect to B via UDP and TCP, A requests a managed session with B from the Manager. the Manager tells B and A to open a new connection with him (through the control channel) and the session will be held by a TCP connection through the Manager. ► Communication is established

8. Session Scenarios Scenario 1: A can open only TCP connection with B Manager Client A Client B Open session with B IP address of B Try UDP and TCP Start Session Ack (for TCP) Scenario 2: A can't open UDP or TCP connection with B, and will connect through the Manager Open session with B IP address of B Try UDP and TCP Time Out Start Session Can't connect to B with B Open TCP with me Ack Start Chat Manager Client A Client B Ack

9. Data Integrity Over UDP ► UDP session starts with Connection establishment. ► Stop and Wait ► Exponential back-off is used when time-out is reached.  Exponentially incremented time periods between resent messages  Linearly decremented when messages are acked

10. Modules ► The project will consist of 2 main modules: ► The P2P Manager module. ► The P2P Client module.

11. Manager Manager

12. The P2P manager module The Clients database component ► Each entry represents a singed-in user with the following fields: ► unique ID (user name) ► Current IP address ► TCP and UDP ports. ► Status ► Open TCP Control socket (Opened during sign-in and kept alive for control messages)

13. The P2P manager module Main Control Thread ► Initializes a listener socket that waits for TCP connections on port 80. This port is used because most likely that it will be opened on most firewalls. ► Once a connection is successfully obtained, the sign-in protocol will take place. Its purpose is to fill in all the fields in the Client DB. The new socket for the connection is also stored in the DB. ► Client’s data is not removed from the DB at sign out, only their status is changed. ► During the sign-in process, the client will get a unique ID and will be inserted to the Clients DB with its IP address and the current connection as the Control connection. ► The control thread will monitor the client sockets. On arrival of a request from A to talk to B will mediate their conversation if necessary. ► Update clients on other clients status. There is a choice between manual updates (client requested) or automatic updates (by the manager - when there is a status change in clients).

14. The P2P manager module Session Class ► Encapsulates a conversation between peers. ► A Session object is created only after the Manager decided he needs to mediate the conversation. ► The Manager will instruct both A and B (via their Control connections) to open new connections with him and pass them to the session object. ► The session object will control the conversation in its own thread.

15. Client Client

16. The P2P client module Main thread ► The client opens a connection to the manager (port 80) and completes the sign-in protocol. This connection remains open until the client signs out (control socket). It will be used for control messages between the client and the manager. ► Creates a connectivity-check thread that will listen on the open ports. ► Creates a session object that handles a direct conversation (if needed). ► Handles requests from the user on updates of other clients status.

17. P2P client module Connectivity thread ► will notify the manager on which ports he listens to UDP and TCP connectivity checks. ► Answers connectivity checks made to these ports.

18. P2P client module Client Session Class ► The client session encapsulates a conversation. ► The type of connection is defined by the connection protocol (UDP or TCP). ► The session is handled by a separate thread.

19. Communication data

20. Packet structure OPCODE(4 Bytes) Length(4 Bytes) DATA

21. OPCODEs SIGN_IN SIGN_IN SIGN_OUT, SIGN_OUT, UPDATE_LIST, UPDATE_LIST, NEW_SESSION, NEW_SESSION, START_SESSION, START_SESSION, NEW_MANAGED_SESSION, NEW_MANAGED_SESSION, JOIN_MANAGED_SESSION, JOIN_MANAGED_SESSION, SESSION_DATA, SESSION_DATA, END_SESSION, END_SESSION, ACK, ACK, CONNECT_TO_MANAGER, CONNECT_TO_MANAGER, USER_EXISTS, USER_EXISTS, ERROR, ERROR, UDP_CONN_TEST, UDP_CONN_TEST, OPEN_DIRECT_CHAT_TCP, OPEN_DIRECT_CHAT_TCP, OPEN_DIRECT_CHAT_UDP, OPEN_DIRECT_CHAT_UDP, END_CHAT END_CHAT

22. And now: Demo !!!!