Subject: Plans for Jade utilisation
From: Domènec Sos i Vallès (DSV@nextret.net)
Date: Tue Nov 26 2002 - 12:10:47 MET
Hi all,
this is my first message to the list. In brief, I'd like to explain the two
projects in which the usage of Jade may be useful for me. Comments will be
highly appreciated.
* 1.- The radio network project
First project is for a Spanish telco company (so, not Telecom Italia :-)
They have a network that broadcasts radio, and an application that controls
seven uplink to the satellite stations a sample downlink station and an
uplink backup station. All the base band and high frequency equipment can be
monitored and configured by means of a serial interface. Current app uses an
NT PC with a serial multiport card and 9600bps links to each station, which
in terms of performance, s*cks.
The new scenario is using the all-new IP management network, with 2Mbps
links to each station (shared with other management apps). IP to serial
conversors will be used and each equipment would be identified with an
IP-addres:TCP-port pair. This means that we can communicate with each
equipment (codecs, modulators, switches, amplifiers) in parallel, not
waiting for the line to the station to be free (forgot to mention, current
serial link is RS485 sharing the same port for several equipments, also when
an equipment hangs, all the line hangs).
How would I like to use Jade? First, create an agent container for each
station (basically for creating a clean distribution of agents in the GUI
view). Then for each station have a master station agent that would be
informed on which kind of operations are to be done against the station
(polling, configuring, shutting up/down). The master station agent would
then instruct equipment agents, one per equipment. These agents would be in
charge of doing all the tasks in which communication with the equipments are
involved. At the end, an administrative container would contain agents for
controlling the operation of the whole network. For instance, if part of the
equipment in a station fails, then main control must tell the whole station
to shutdown and instruct the backup station to configure itself with the
failing station parameters and start transmitting. This is an important
issue, provided that if two uplinks illuminate the same channel of the
satellite at the same time it could be overburnt, and you can't send someone
up there to replace the piece and do Ctrl-Alt-Del :-)
Another interesting issue out of what we're paid for doing. This system
generates alarms. In another environment, alarms may be sent via SNMP to
some console and then combined to generate higher level alarms. This is not
the case, so do you know of some sort of Java inference engine in which
rules can be defined for combining alarms in a declarative way?
* 2.- The sniffer project
A bank asked as to do sort of an IP network traffic analyzer. This is, a
sniffer that rather than writting a log to a file permanently, sniffs
packets, identifies communications, then classifies these communications
according to the services of a bank (basically a service is identified by
the IP/port of the server) and according to the originating office (an
office is the set of IP's of the machines there). When this categorization
is done, and aggregation according to some bank-significant hierarchies
(say, all the offices in a regional organization) must be done and finally
alarms and historic performance records are generated. Nice project, too.
Current traffic is of some 50Mbps, which is well below the 100% of packets
captured on a 100Mbps network with a P-III 400MHz that the authors of
Libpcap reached. Surfing the net, I've seen the Pentium-IV being able to
sniff up to near 300Mbps. Question I ask myself is: what will grow faster,
hardware power or bandwidth hunger? Seems to be that at present we have an
starting advantage. All this sniffing, classifying and aggregating processes
will be done in "C" language looking for ultimate speed and performance.
In terms of workload distribution, sniffing and communication identification
will be distributed across several machines, each one looking for a subset
of IP's. Each sniffer would generate UDP datagrams with first level
aggregated information, basically "there has been a communication from
IP/port to IP/port that took so many bytes and happened between time 1 and 2
and had some interesting events of the protocol happening at a given time".
Format of the UDP packet would be quite similar to Cisco Netflow format. We
don't use NetFlow because 1) one of the requirements was to be not intrusive
on the network switches and 2) because Netflow does not allow you to inspect
the packet content, which can be used for a higher level of inspection. At
the second level of aggregation machines would recollect the UDP
Netflow-like datagrams and do the aggregation in terms of bank-sensitive
criteria.
The process itself is all C developed for performance issues. But notice
that we have several machines distributed, and that having a standby machine
for each proces for an 99.999% uptime (well, almost :-) is important. So I
considered that having Jade agents distributed in each machine could be
useful. Each Jade agent could be used to poll the machine local status, to
receive new configurations, and to be instructed by a central control agent
of what to do. Say, if sniffer SnfC1 fails, control would tell sniffer SnfC2
to start sending datagrams to the second level in replacement of SnfC1
(provided that both sniffers were doing the same job).
For the Java-C interface, there are several possibilities. So far I've read
that JNI overhead is in the microseconds range, whereas the overhead for
opening a socket is in the miliseconds range. But what about to IIOP
overhead? Before deciding anything by myself, I think that I should better
ask the Jade gurus who know a lot more in this aspect. Any idea bout this?
Thanks all for your time reading this, and for any suggestion/enlightening
idea/criticism that may come.
Domènec Sos Vallès mailto:dsv@nextret.net
Consultant - Software Services
________________________________________________
NexTReT - eBusiness Solutions http://www.nextret.net
Paseo Bonanova, 9 08022 Barcelona Spain
Calle Fortuny, 3 28010 Madrid Spain
Tf. (+34) 932 541 530 Fx. (+34) 934 175 062
________________________________________________
Nota Legal: Este correo electrónico puede contener información confidencial
y es de uso exclusivo del destinatario, quedando prohibida a cualquier otra
persona su revelación, copia, distribución, o el ejercicio de cualquier
acción relativa a su contenido. Si ha recibido este correo electrónico por
error, por favor comuníquelo al remitente, y posteriormente proceda a
borrarlo de su sistema. Gracias por su colaboración.
________________________________________________
This archive was generated by hypermail 2a22 : Tue Nov 26 2002 - 12:09:38 MET