When developping distributed applications, the developper is confronted with several challenges. Madkit offers an important advantage making the communication of agents in different kernels transparent.
MadKit offers two different modules to enable Kernels in different machines to communicate. The original module is the Communicator and, since Madkit 4, NetComm.
Other important point to notice is that the communicator is designed as a single agent. This makes the extension of the communicator (eg. adding new communication protocol) rather difficult.
The Netcomm module was designed to tackle all these problems.The Netcomm Module was designed as a multi-agent system, where a Single agent is used as an interface with the localkernel to make the change of the communications module transparent to the Site Agent.
This "interface" Agent, called NetAgent, takes the place of the communicator agent and redistributes the messages to the concerned agents.
Most people won't need any special configuration and can use the NetComm Module "out-of-the-box". The main agent in the module is the NetAgent. You will only interact with this agent, the other agents in the module have specific roles in the organization. You can interact with the NetAgent either thought its Graphical Interface, or using its API.
In this section I suppose you have an installed and working Madkit Desktop. If not, take a look at the PluginManager Agent to install and update your madkit plugins.
1:import madkit.kernel.*; 2:import madkit.netcomm.*; 3: 4:public class MAS{ 5: private Kernel kernel; 6: 7: private void initMAS(){ 8: NetAgent net=new NetAgent(); 9: net.setAutoBroadcast(true); 10: kernel.launchAgent(net, "netagent", this, false); 11: } 12: 13: //rest of the class omitted 14: 15:}
The default order is:
A more complete guide can be found at http://java.sun.com/j2se/1.4.1/docs/guide/security/jsse/JSSERefGuide.html
$ keytool -genkey -alias netcomm -keyalg RSA -validity 7 -keystore madkitkeystore Enter keystore password: madkit What is your first and last name? [Unknown]: NetComm What is the name of your organizational unit? [Unknown]: Communications What is the name of your organization? [Unknown]: Madkit.org What is the name of your City or Locality? [Unknown]: France What is the name of your State or Province? [Unknown]: France What is the two-letter country code for this unit? [Unknown]: FR Is CN=NetComm, OU=Communications, O=Madkit.org, L=France, ST=France, C=FR correct? [no]: yes Enter key password for <netcomm> (RETURN if same as keystore password):
$ keytool -list -v -keystore madkitkeystore Enter keystore password: madkit Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry Alias name: madkit Creation date: Dec 5, 2003 Entry type: keyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=Netcomm, OU=Communications, O=Madkit.org, L=France, ST=France, C=FR Issuer: CN=Netcomm, OU=Communications, O=Madkit.org, L=France, ST=France, C=FR Serial number: 3fd09c7f Valid from: Fri Dec 05 15:55:59 CET 2003 until: Thu Mar 04 15:55:59 CET 2004 Certificate fingerprints: MD5: 8C:14:B2:DB:16:A9:62:83:25:60:78:83:8B:D4:A9:D0 SHA1: 87:18:AA:9F:C9:AD:25:6C:0E:14:48:D7:42:57:57:AC:A7:CC:ED:DF
$ keytool -export -alias netcomm -keystore madkitkeystore -rfc -file netcomm.cer Enter keystore password: madkit Certificate stored in file <netcomm.cer> \$ cat netcomm.cer -----BEGIN CERTIFICATE----- MIICUDCCAbkCBEAWprwwDQYJKoZIhvcNAQEEBQAwbzELMAkGA1UEBhMCRlIxDzANBgNVBAgTBkZy YW5jZTEPMA0GA1UEBxMGRnJhbmNlMRMwEQYDVQQKEwpNYWRraXQub3JnMRcwFQYDVQQLEw5Db21t dW5pY2F0aW9uczEQMA4GA1UEAxMHTmV0Q29tbTAeFw0wNDAxMjcxNzU4MjBaFw0wNDAyMDMxNzU4 MjBaMG8xCzAJBgNVBAYTAkZSMQ8wDQYDVQQIEwZGcmFuY2UxDzANBgNVBAcTBkZyYW5jZTETMBEG A1UEChMKTWFka2l0Lm9yZzEXMBUGA1UECxMOQ29tbXVuaWNhdGlvbnMxEDAOBgNVBAMTB05ldENv bW0wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL5iUqSr/QdH/BYInlFmUBCHADxyVR6Hkk1N s+jpKcH2aWKcxwBkUt4S9ti4BI+rGk7JHDlg4rDIml53igF3kSesYPUxSIDCPe0FFpYvUTlvI0I3 sauKZ1/Cb7ys69gItfJTx2oYJpooest4L2tlA6iiWOez01YIue/v4KkozimPAgMBAAEwDQYJKoZI hvcNAQEEBQADgYEAnNEX3sX8ZG2g2rxIOM1erxd4qSstKYrLPEkJY1IYSsiD+dPEQ9N9cdmaXL6i TcZWGKmWmQ3bUoGFBYhGgCxCFSL/c4aO9XykgCJAOexwk9Pgl/L/K5L8IeexFl2QdRiokp8udd14 SknBHBEWDhbodUbyB+RVFjEhaBAvcx1afWw= -----END CERTIFICATE-----
$ keytool -import -alias netcommcert -file netcomm.cer -keystore madkittruststore Enter keystore password: madkit Owner: CN=NetComm, OU=Communications, O=Madkit.org, L=France, ST=France, C=FR Issuer: CN=NetComm, OU=Communications, O=Madkit.org, L=France, ST=France, C=FR Serial number: 4016a6bc Valid from: Tue Jan 27 18:58:20 CET 2004 until: Tue Feb 03 18:58:20 CET 2004 Certificate fingerprints: MD5: E2:DC:92:8B:84:68:4A:2E:C0:6B:78:3E:FA:68:6B:F0 SHA1: 6E:7C:62:37:D6:B3:4B:3F:82:E0:5D:C0:F8:90:C1:93:55:82:A3:D3 Trust this certificate? [no]: yes Certificate was added to keystore
-Djavax.net.ssl.trustStore=<your truststore>
-Djavax.net.ssl.trustStorePassword=<your trustword>
NetComm lets you define your own connection rules. This lets you define which protocols to use with specific hosts. The location of the files that contains the rules is defined using the variable "madkit.netcomm.rules"
Actions:
The second specifies that when an incoming connection is received from pc1.utbm.fr, the connection will be accepted and the protocol order is set to simplesslprotocol and then communicatorprotocol.
All other connections match *.utbm.fr or *.fr will be closed.
An import thing to notice, is that netcomm will search in the order that the rules were defined and will return the action of the first match.
<?xml version="1.0"?> <rules> <defaultrule action="refuse" arg="I don't know you"/> <rule match="pc1\u002Eutbm\u002Efr" action="accept" arg="simplesslprotocol:communicatorprotocol"/> <rule match=".*\u002Eutbm\u002Efr" action="refuse" arg="Sorry"/> <rule match=".*fr" action="reject" arg=""/> </rules>
Well this feature should actually be called Multicast, since NetComm relies on IP Multicast to announce its presence in the network.
Basically, when the NetComm Agents are launched one of those agents is created to listen for Multicast Messages. Every time a new message arrives the BroadcastListener will launch an agent to configure the connection with the new kernel.
One of the advantages is that you don't need to know where are the other kernels, you simple inform every one of your presence and they will contact the local kernel.
Technically, in Multicast you have to join a IP Group, Madkit default Multicast Group is 239.239.239.239 . This group is a reserved to Organizations. This means that Datagrams will not go outside your organization's network. In the current version, you can not change this group, future releases will include the possibility to define the Group you want to join. This will also open the possibility of having multiple Kernel networks.
What? Well, when an agent joins an IP Group, it only receives the datagrams sent in that Group. So if you configure one group of kernels to listen in 239.239.239.239 and another in 239.239.239.238 both groups will remains separate, and you will have two sets of interconnected kernels.
mmm.. interesting.. but is this useful in any way? Well, that depends.. it depends on what you are using madkit for. Imagine you have to perform heavy distributed simulations and at the same time you have, lets say, agents that help your personal in their every day work. You probably don't want you simulation Agent bringing all the computers with a Madkit kernel to its knees.
This feature enable you to use specific protocol according to you communication needs. For instance, the MultipleSocketv1 Protocol uses only one agent to handle the communication among several kernels as long they don't share a community. This lets you save valuable resources and keeps your kernels connected.
In the future we hope to provide a set of different protocols to provide SSL Communication, Communications thought HTTP, etc.
In the time begging the StatAgent reports only through its graphical interface. However future work will enable this agent to log the network traffic in a file for later analysis.
The next figure represents the relation between the different agents.
NetComm uses 4 different ports
If you are using a firewall, please check that it is not blocking the ports required by NetComm to communicate.
NetComm uses an IP Multicast Group with a scope of one organization, it is currently not possible to change this value. Future releases with provide a way to configure it. In other words, the multicast message will not go outside the local network. If you are trying to connect two host with a distance higher of 1, the problem is that the message simply doesn't get to the remote host.