Proposal for a rewrite of communication architecture to facilitate the UDP protocol

[DoubleCouponDay]

As of commit 5af720f, hole punching times out when using TCP. The current theory is that UDP is more widely accepted by NATs and will allow certain packets to be considered as part of the same session during the switch from client-server to client-client communication. To test this theory, we need to make the following changes to the code:

• Allow users to input their chosen protocol as string argument,
• Create a new protocol class which can validate the chosen protocol and prepare socket specific config enums,
• Refactor the constructors of all socket abstraction classes to accept the protocol class as argument,
• Store the protocol class in the base classes LinuxSocket and WindowsSocket,
• Create a function in the protocol class that will handle protocol specific message waiting behaviour,
• Refactor authentication communication to have a more general request-response architecture,
• Somehow keep the message queue stuff.
• Server assigns a leader flag to the first client to enter the READY_FOR_P2P state.
• Create a new message type called HOLE_PUNCH which is sent simultaneously between peers.
• The client with the leader flag will send the first hole punched request after hole punching succeeds.
• Refactor sending messages into a protocol class function so that both protocols can be abstracted over.

RFC.

[Bobscorn]

Also for the Rendezvous server it will need to listen with two sockets, one for udp, one for tcp, and on different ports:

• Have server Listen with two sockets on different protocols
• Have client connect using correct port for protocol
• Server maintains two 'sessions' one for udp, one for tcp? (otherwise what happens when a udp client connects, and then a tcp client, can't really hole punch tcp-udp)

[DoubleCouponDay]

I discovered that UDP sockets do not support listening on Linux and Windows.

[DoubleCouponDay]

Completed in 4de33a0