Dustin Wong

1
By Dustin Wong Terrence Irving Benjamin
Minkowsky
2
Introduction

• Project Overview
• Connection protocol
• Discussion of features
• Chat, Games Chess
• Plug-in ready architecture
• Protocol Evolution
• How to get around NATs
• In the works
• Scope things considered but not pursued
• Example session

3
Project Overview

• P2P networking framework
• Chat, games
• Plug-in ready
• Adding new features is simple and easy
• Central server
• Name aliasing
• Initiates connections
• Secure connections (encrypted)
• NATs OK!

4
Central Server

• Maintains list of online users
• Name aliasing
• Holds state information
• NAT status
• Update upon login/logout
• Initiates connections
• Both live/one live, one NATd/both NATd
• Accept/decline

5
Opening a New Connection

• P2P connections
• Accept/Decline pop-up window
• Three network scenarios determined by server
• Control message protocol sent via server
• If accepted, a direct socket is created
• Called a session

6
Opening a new Activity

• Within a session users can open a new
  activity
• New Socket for each activity
• Chat
• Games Chess

7
Chat Chess

• Two plug-ins bare-bones implementation to
  illustrate framework functionality
• Chat
• via TCP
• User Aliases
• Chess
• Play online

8
Plug-in-ready Architecture

• Allows users to develop their own plug-ins for
  WIMSockle
• Not much concentration spent on developing
  activities (just extra)

9
Protocol

• XML-based
• Allows for simple, clean use of tags
• Somewhat similar to TCPs call/answer protocol
• Reaction occurs for many actions
• Protocol is basically the same whether a
  Client-server connection is being established, a
  Client-Client connection is being established, or
  an activity is running between two Clients

10
Protocol Evolution
11
Three Network Scenarios
12
How to Handle NATs

• Server initiates the connection
• Sends protocol messages to clients
• One live, one NATd
• NATd Client is instructed by server to call live
  Client
• Both NATd
• Server (proxy with live IP) establishes socket
  connections with both Clients and pipes data
  between the two

13
Session Examples

• Log-in

Client C ben.com

1
2
Client A terrence.irving
Server

2
3
nameben.com /
Client B dustin.wong
14
Session Examples (contd)

• Log-out

Client C ben.com


1
3
Client A terrence.irving
Server

3
2

Client B dustin.wong
15
Session Examples (contd)

• Declined connection

Client C ben.com
1
Client A terrence.irving
Server
4


2
3
Client B dustin.wong

16
Session Examples (contd)

• Accepted connection, recipient has live IP
  address (sender is NATd or live)

1
Client C ben.com
Client A terrence.irving
Server
4
/

2
5
6
3

Client B dustin.wong
aredustin.wong
7
areterrence.irving
17
Session Examples (contd)

• Accepted connection, recipient is NATd

Client C ben.com
1
Client A terrence.irving
Server
4

ipterrence.ip.address /
2
5
6
3
7

Client B dustin.wong
areterrence.irving
aredustin.wong
18
Session Examples (contd)

• Accepted connection, both sender and recipient
  are NATd

Client C ben.com
1
Client A terrence.irving
Server
4
2

3


5
5
Client B dustin.wong
/
/
6
Pipe established
19
In the works.

• Logging in
• DND authentication
• Currently works only in the Dartmouth realm
• Possible global implementation to make it work
  outside of Dartmouth
• Network security

20
Secure Connections

• SHA-1 with DSA authentication
• public key/private key
• Secure Socket Layer (SSL) Protocol
• DSA encryption for scenario where Clients are
  both NATd
• Encrypt data from proxy
• SSL cannot tunnel through NATs

21
Scope

• Certain aspects were considered but not pursued

• Scalability
• Not an objective to begin with
• Versatility
• Essence of WIMSockle is that user-base adds to
  its functionality by developing plug-ins
• User-friendliness
• Such an attribute comes with time and further
  development

22
Demo

• Live demonstration