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.