Creates a chat channel for every running torrent, allowing you to chat with other peers on the same torrent.
The Chat Plugin uses Azureus' enhanced messaging, with the following messages :
The current version of the Chat Protocol is (byte)2.
CHATNOROUTE and CHAT_ROUTE have no payload.
CHAT_MESSAGE has a payload which is composed of a bencoded dictionary containing the following values :
- "id" : the message ID (integer) (32bit integer in the Azureus implementation)
- "s" : the sender peer ID (String)
- "n" : the sender nick (String)
- "h" : the number of hops the message has been trough so far
- "t" : the content of the message
Routing Overall Mechanism
The main idea is that each peer will choose from which peers he will receive messages, currently (as of verison 1.8.1) each peer chooses 5 peers to receive messages from (we'll call those peers "routers"). The number 5 has be chosen in order to limit the "net split" effect. However, it may change with time. The more the number of peers that will relay messages to us, the more likely messages are routed to everyone, but the bigger the overhead. In order to tell a peer that he should forwardyou all the messages he receives, you send him a CHAT_ROUTE message. If you want to cancel it, you send him a CHATNOROUTE message.
Electing peers to be "routers" for you
The current process is as follows :
- As long as you don't have 5 "routers" any new peer becomes a router (and so is sent a CHAT_ROUTE message).
- Once you have 5 routers, every time a new peer connects to you, he has a probability to become a router equal to 5 divided by the number of peers you are connected to. (ie, if you are connected to 20 peers, he has a probabily of 1/4 - 5 / 20 - of becoming a router). If he becomes a new router, then the oldest router you had is discarded as a router (and so is sent a CHATNOROUTE message).
Receiving a message
The list of IDs of messages received needs to be maintained. Currently, in Azureus, each torrent (and so, channel), has its own list, and each list is 512 messages long (Oldest IDs get dropped). When a message is received, if it has already been received (checked by message id) it is dropped and NO processing is made. If it hasn't been received, its id is added to the list of IDs of messages received (note that this process must be synchronized with the checking process in order to filter duplicates coming in from several peers at the same time). Then, the message is forwarded to all peers for which we are a router. During this process the number of hops value is increased by one. A limit on the number of hops is in place, and the current limit is 10 (ie, a message with 10 hops won't be relayed anymore). The Message ID MUST NOT CHANGE in the forwarding process. The message can also be dispatched to the UI in order to be displayed.
Sending a message
When a peer has to send a message, he constructs the message, and has to allocate a message ID for this message. The message ID can be any integer (32bits integer), requirements are is that it must be unique for all messages. Azureus uses the java hashCode of the string made of the senderID + "," + the current time in ms + "," + the message text. The message is then sent to ALL connected peers.
- Flood Control : flood control is handled locally, with a limit of 1 message per 5 seconds.
- Ignore : Ignoring a peer also stops you from routing messages originating from him.
- emotes : emotes are sent as normal messages, and are handled at the display level.
- System messages : system messages are simulated by sending an emote with the nick "System"
Back to Plugin List