(4) Peer To Peer Chat Tutorial in Go

Concept

Keeping track of all the code in your head can become very difficult very quickly. Let us abstract away everything our flood fill network is doing, and just make it easy to build on top of. We will end up with an interface of only two functions, Read and Write. Below we see the complex network, but from the individual nodes perspective working through the interface, they only see messages entering and leaving the network.

Along with this cosmetic changes, lets add a tiny more functionality. We want to maintain a minimum number of connections at all times so that even if we lose a connection, we can quickly find another and not lose the network. A good number might be five, since the chances of all five people disconnecting at once are essentially zero. There is a consequence to this addition though.

Now people can connect to each other twice, once from A to B, and another from B to A. Since the ports used on a computer are different when receiving a connection and sending one out, A and B don't recognize the others second request since its coming from a different port. We have an issue of identity. We could just use IP instead of IP:port, but that would make development harder and probably lead to unknown consequences in the future. Instead lets just include our listening address when we send out a join acknowledgment, then people can store peoples listening addresses and make sure not to connect to the same person twice.

Once we fix that, we have a new issue. Right now a join request will be bounced between a network of two nodes forever. In a fully connected network, no one will accept a JOIN_REQ, because they're already connected. In order to fix this, we will add a counter to each packet. The counter will decrement on every hop, then, after too many hops the packet will be dropped.

Code

We will create a 'Network' object which can contain all of our data, and all our methods can be attached too. This will make it easier to work with later, and will even allow us later on to interact with multiple networks at once within a single program.

We will also change our packet to transmit arbitrary data. We will regress for a moment, so now our packets don't contain 'Origin' or 'Message', they just have a byte array called 'Payload'. Then on top of this network we will add back the chat application which has a message and origin.

The network needs an interface that is as abstract as possible so we can forget everything that's happening beneath. All we want from our network is the ability to read and write from it. The user will be oblivious to the joining mechanism or the flooding, they will only see that they can send and receive messages.

In a new folder I have called 'floodnet', we will place our more general flood network. Then in the root folder we have a main file which reads users input and passes it into the network, oblivious as to how it is being done. I have my module named 'P2PChatTutorial4', which will be apart of the path we use to import the floodnet module we are making, so make sure to change it to whatever you've named your package as.

We will also use a Go channel to track incoming and outgoing connection requests through a single routine, this way we don't accidentally have two routines accept a request from the same individual.

floodnet/network.go

floodnet/joining.go

main.go

Now try running as many terminals as you wish. For debugging you will see every connection you have after you send a message. For the moment we actually seem to have regressed since we no longer printing the senders address. But now we can have an arbitrary number of connections, and most importantly, the flood network can be forgotten about (until we want more features), and new applications built easily on top of.

go build -o chat && ./chat

Next

We want to turn it back into a chat application, and add direct messaging. Following the next post we will add some security to direct messaging.