Some Usability issues with the Internet

This section discusses various connection techniques used on the internet, some issues regarding them and various minor solutions to them.

Setting up a server

This section discusses issues with setting up a service. The first case is setting up a game server, which doesn't support Upnp, and therefore will require configuration of the router/firewall to use. The relevent use case for this scenario is:

Use Case for a user setting up a Non Upnp game service
User Actions	Firewall settings	game actions
	1. Firewall is set to secure state, All ports are blocked on the system by default.
2. User starts game server		3. Game opens a listening port on the system for clients to connect to.
	4. Firewall prevents connections to listening port
5. To allow user to join, User opens up service port manually
	6. Firewall opens port to internet. Any IP can connect to the server, allowing any hacker to compromise the service

In this case, knowledge of IP's, firewalls and ports are required to get the system working properly. The better solution is to use Upnp which doesn't require any manual configuration.In the case that the program supports the upnp protocol, which is used to dynamically open ports, and redirect ports on routers to the correct system on the network, the relevant use case is:

Alternative Use Case for a user setting up a Upnp Based service
User Actions	Firewall settings	Game Actions
	1. Firewall is set to secure state, All ports are blocked on the system by default.
2. User starts game		3. Game opens a listening port on the system for clients to connect to, and uses Upnp to tell the firewall to open the port so people on the internet can join
	4. Firewall automatically opens port for the game, allowing any user from the internet to join the game (melicious or not).

While upnp does reduce the amount of configuration required, and should be employed by all services to reduce the configuration required by users, it is no more secure then manually opening a port.

Some limitations of setting up a service currently

With the advance of broadband, many users are behind at least 1 or 2 firewalls/routers. This often leads to difficulties in setting up the servers, and in most situations, computer illiterate people are unable to set up the simplest of servers, and at least one manual must be read to configure the routers properly. Upnp solves this problem to an extent.
Because services are normally distiguished by both port and IP address, on a system where a user wishes to run 2 copies of the same server type, they must manually change the port on the second one to a different, unused one, and they need to specifically notify all friends who wish to join that they have done so. It becomes even more difficult to set up 2 copies of the same type of service on a large network, where 2 or 3 users may want to share a service on the internet from different computers, yet will suffer Upnp problems/forwarding problems when they try due to trying to use the same ports. It is often difficult to diagnose because both services will work within the network, but only one will work on the internet. In fact, depending on the design of the program, if its designed to override other forwarded ports with its own, a race condition will occur, and both services will keep racing to have the port forwarded to their computer. Because of this, large networks are barely able to allow users to offer their own services, because it can quickly become a disaster.
If the service is set up on a connection that suffers disconnections regularly, and the service changes its IP every time it reconnects to the internet, users of the service may lose connectivity. An example is if they are downloading data from the connection overnight, and the server disconnects and reconnects to the internet, changing its IP. The download will remain stopped until there is user intervention (on the users side), as the server's IP they would be connected to may be invalid. The only easy way to fix this is to either pay for a DNS address, use a ISP that provides a static IP, or sign up to a dynamic DNS service.
Knowledge about ports and finding your own IP are needed so that friends or others can connect. Unfortunately, it is as difficult to set up a small server quickly amongst friends as it is to set up a larger one for a lot more people. At the very least, the use of ports should be abstracted away from the high level functions which users perform, and users should not need to know such information. While it does make sense for large servers to have a universal means of a server address, smaller ones only generally need enough information that friends can connect easily, which generally means trading usability for compatibility (ie. they would need resonance to access the service).

Connecting to a service

This section deals with connecting to another users services. As you will see, it is a lot harder then it should be. Its best to start with a simple example of connecting to a game server which has been set up on a standard server (which doesn't have any form of security).

Use Case for joining a game service on a standard server
Server owner	User joining the server	Game	Firewall
2. Owner informs friend that game has been started and locates his IP which is given to the user. He also grabs the port number the game is on (if on a larger server), and gives that to the user as well	3. User sets up a connection on the port and IP specified by the owner. The IP and port often needs to be written down to avoid needing to switch between windows in the game setup (as some games crash when doing so).	4. Game attempts to establish a connection to the target system. If the connection if successfully established, the user is added to the game.	1. Firewall state is set to allowing connections on the correct port, and connection forwarding has been set up already if needed.

As you can see, the IP and port are needed to be determined by the server owner to set up a server. Simply determining their IP is normally beyond the knowledge of most users. Even worse, if the firewall isn't configured properly and is set to ignore connections, the user could be waiting a minute or so before knowing that its not connecting. Now, assuming that the server owner is very paranoid, and is setting up a service known to be a bit insecure, if he wants to be secure, he'd have to only allow the set ip's of his friends onto the service. To do so involves adding them to his firewall. An example use case is below on this situation:

Use Case for joining a game service on a secure system
Server owner	User joining the server	Game	Firewall
1. Owner informs friend that game server has been started and requests their friends IP address so that they can allow them to connect.	2. Friend manually finds ip and gives to owner
3. Server owner adds IP to firewall, to allow them to join the game			4. Firewall starts accepting connections from the user, on the game port
5. Looks up their IP manually, and gives both the game port and IP to their friend	6. Friend joins server using IP and port	7. Game connects to target system. Once connection is established, game begins.	8. Firewall permits connection

It soon becomes blatantly obvious that setting up a server that only permits certain friends to join can be a difficult task unfortunately, and most of the actions needed to be performed by the user can be difficult.

Current Issues with joining any server

The server IP needs to be determined and transmitted to the friend, which usually involves sending it over an Instant messaging network. Unfortunately, working out your own IP can be a bit taunting sometimes, especially to new users as they may accidently grab their internal network IP (which normally looks something like 192.168.*.*, or 10.*.*.*), instead of the ip the internet uses to refer to them, so users wont be able to connect until they work out the correct one
Remembering IP's to put into the game isn't difficult as it is only 4 different numbers (32-bit). When the new internet protocol gets released however, everyones IP's will be 128 bit and will be a combination of Hexadecimal digits, and will therefore be at least 4X more complex to remember, so it would be preferred if the use of IP's could be avoided entirely.
Users should have no need to stoop to low level Internet addressing mechanisms such as IP addresses, and it can be almost guaranteed, that especially in buggy games that may crash or have issues with switching out of the game, that the user will have to write down the IP address on a sheet of paper which can be very inconvenient.
Users should not need to manage the ports of their services, nor should they need to tell their friends the port. Another problem is that if there is when 2 copies of a server are started (1 maybe by another user), where one is set up on the default port, many people may accidently forget to change the port setting and be sent to the one on the default port, even if it is not the service they want. In fact, if another user sets up a server for only their friends on a specific port, there is no reason why another users friends should be able to see it without being given explicit permission to.
Potentially interested friends will not know a service exists until they are informed. This applies especially in the case of gaming servers, where users often prefer to play against as many other people as possible, and as many people they know as possible. However, its difficult to contact all their friends about it. If they were constantly informed of their options, in a non intrusive way, life could be like one long constant LAN party (basically a party where you play multiplayer games and share files, etc all night long).
If the server admin wishes to change the servers port or/and change their IP, chaos occurs, and users who may have disconnected just before the administrator sent out the message to people in the game may not be able to reconnect without asking the service administrator for the new details.

Issues regarding joining services on 'secured servers'

Both Parties need to know each others IP address before being able to connect to each other, which normally involves sending them over an Instant messaging network. Unfortunately, working out your own IP can be a bit taunting sometimes, especially to new users as they may accidently grab their internal network IP (which normally looks something like 192.168.*.*, or 10.*.*.*), instead of the ip the internet uses to refer to them, and on secured servers, both users need to be able to do it to succeed.

Zeroconf technologies

Zeroconf systems are designed to facilitate service broadcasting over a small network, allowing different computers to see which services are available on different computers on the network. This can be helpful because it allows users to completely avoid needing any internal network IP's, or worry about knowing the port numbers of other users service's to connect them. While most of the current implementations (such as Rendezvous/Bon Jour) are definitely a step in the correct direction of service sharing over a network, they do not perform at all over the internet, which is its major drawback. Resonance is being designed to simply supplement such technologies, to allow both internet, and internal network to be covered.