Multithreading

One of the big problems that I have been struggling with today has been chase errors and multithreading. I have finally managed to figure out how to solve the biggest error that was occuring. When I sent a request for a name list from a telnet connection to the peer the response is duplicated on occasion. I used mtuexes everywhere, which in hindsight could have been a problem because of dealicks. I eventually figured out I should consolidate it into two iterators, one for queued relay messages one from peer and one for all of the received messages. By placing a mutex around the iterator it doesn't have any troubles anymore.

Chase Errors

I have noticed that every time that I run the application it is producing un-reliable output. I think that it may be down to chase errors. I might need to use a couple of mutx locks to prevent there from being any problems. So I think I will implement a few mutex locks. Here is a good wiki article on mutexs in computer programming. http://en.wikipedia.org/wiki/Mutual_exclusion

Broadcast

Although I have not actually done any work on the code since my last post because of educational commitments but I am looking forward to making some changes and perfecting the code.

One of the key concerns in designing a peer to peer network is the scope of messages that are sent from one peer to another. Presently there is local messaging from one peer directly to another peer and relaying of messages to other peers though other peers.

There is another form of messaging that could have great potential in peer to peer network. broadcast. This also has the potential to overload a network and destroy its usefulness.

There are two main ways of overcoming this problem in my mind. To understand these you have to understand how broadcast would be implemented in gourami. It would essentailly use the same message path format of the noraml message in gourami. That is user1/user2/user3[protocol]{message}user4/user5/user6. The difference would be that any * would be inteprerated as "broadcast". So a broadcast message would look like: */*/*[protocol]{message}user4/user5/user6. Each itteration from peer to peer would add to the sender path just as ususal but it would be able to exponentially propogate though the network. This could be a problem, or extremly usefull.
Spammers may use many * - hops to achieve broad network coverage but doing so would overload the network and flood it with spam messages. To reduce this each peer to check the number of broadcast hops and do either of two things: stop messages that have more than the specified number of hops to go, or change the number of hops to go to the maximum allowable number. I am very hesitant to allow peers to transparently change messages although that could be implemented by anyone. I think either option, or no checking should all be available. Most peers will probably only allow 1 or two levels of broadcast.

Abstraction in Gourami

Due to the fact that Gourami is a framework and a protocol I have been struggling with how to split the project up and at what level to implement various things.
I think that I have now found the right boundry. I have made Peer (renamed from NetworkManagment) inherit from NetworkCommunicator. This meant that I had to to reconcile some of the conflicts of the two classes. I had to, thoughout the process, consider what parts belonged to what level. In doing so I was able to move the process_gourami_message to the Peer level. I am also in the process of considering the relationship between Connection and PeerRecord.
By considering what levels each process occurs on carefully I will hopefullyh build a framework which is easy to deal with.

Preliminary Tests

After a few syntax and include fixes I was very supprised to see that my implementation that I have developed in the test_main.rb file works straight off. This was very pleasing although there is a long way to go with many of the features. At the moment there is very little that is implemented. The next priority is to add error handeling to the framework. I expect that in the next couple of weeks it will become usable for a third party implementation. I have a friend who has offered to test it out and I am hopeful that with his help I will be able to run the first large scale tests of a Gourami network.

Peer Table

As part of the system that allows this peer to peer network to be persistent is peer table. I hope to use the peer table to store a list of peers with a name, ip address (/host name) and port.
Each line of the file will be formatted like so:
name:ip:port:connection_attempts:connection_successes
For exmaple
Adam:123.234.123.234:2305:4:3
This means that there is a peer called Adam who is located at 123.234.123.234 on port 2305. This peer has been attempted to be contacted 4 times but only 3 times were successful. The last two values give an indication of the reliability of the peer.
The peer table is built up over time from peers that have had there ip address and ports logged. This allows for a peer to have a long list of peers that can be connected to without the need to continually need to connect to a 'super-node'.
Some method to clean the peer table should be implemented to remove peers with low reliability. An extended peer table could log times of last connection for cleaning purposes.
This file would not have to be used as it could pose a problem legal / security that a list of peers that have been connected to is present.

Code commented

I have just finished commenting code for maintainability. I have been using #TODO: for an adhoc to do list throughout the code. This is especially useful as it appears as a different colour (purple) in NetBeans 6.5 which makes it easy for me to skin the code to look for things to fix up that I would have otherwise forgotten about but didn't have the time (or couldn't be bothered) at the time to fix.

Blocks and Callbacks

I need to learn how to use blocks and callbacks so I can implement something similar to C# and Java's events. I need to for events such as message_received and peer_disconnected. :-)
I think this site might provide what I am looking for. http://stackoverflow.com/questions/246091/what-is-the-equivalent-of-net-events-in-ruby

Gourami - Project Overview

Gourami is a project which aims to build a dynamic peer to peer network on top of existing technology. Gourami uses the current TCP/IP stack but merges 'servers' with 'clients' to create seamless peers. These peers can then connect to each other and send messages to each other or though each other. Such a network is aimed at decentralising networking.

One of the main benefits for Gourami is its ability to encapsulate protocols. While it may be the case that not all protocols can be accommodated inside Gourami it is envisaged that it will be possible to encapsulate protocols such as HTTP so that peer to peer computing can be used to rout HTTP traffic on the web. This is especially important for those who live in countries where there are restriction on what pages can be accessed.

Why decentralise?

There are a number of shortcomings that are associated with centralised networks that can be avoided in decentralised networks. Decentralised networks do not solve all problems and they are not meant to replace centralised networks but rather as a supplementary alternative.

The main problems associated with decntralised networks:

• Centralised Control - Networks that have a central hub (such as a single server) usually are controlled by some central authority. This is especially worying if that authority cannot be trusted.
• Low Fault Tolerance - Networks that have a central hub often fail when this hub fails.

Decentralised networks overcome can overcome these problems. Gourami aims to overcome these problems though the following systems:

• By using multiple (many) peers for routing traffic on the network is not controlled by any one authority.
• If one peer fails the network does not collapse as traffic can be potentially re-routed around the problem.

These comaprisons are quite vague and I hope to build on these in the future, but it is my beleif that decentralised netowkrs could be especially usefull when trust cannot be placed in a central body. Gourami aims to make it technically and legaly difficult to "control" the system so as to avoid undue interferance.

Note

"Centralised and decentralised networks" are terms that I have really invented out of thin air. To explain what I mean I would consider the use of a single server or server cluster for the provision of services, exempli gratia messaging. I am aiming to avoid this by developing the Gourami framework.