While it is possible to devise a global service where each job registers
its jobid together with the address of the appropriate database, such a
service could easily become a bottleneck. We opted for another solution,
-to keep the address of the \LB database within the jobid. This way,
-finding appropriate \LB database address becomes a local operation
+to keep the address of the \LB database within the jobid (actually,
+fully qualified hostname is strongly recommended instead of numeric address
+and numeric IPv6 address is not supported for backward compatibility reasons).
+This way, finding appropriate \LB database address becomes a local operation
(at most parsing the jobid) and users can use the same mechanism when
connecting to the \LB database to retrieve information about a particular
job (users know its jobid). To simplify the situation even further,
- all communication in LB must be modified to fully support IPv6
- affected modules: [org.glite.]jobid, security.gss, security.gsoap-plugin, lb.common,
lb.client, lb.logger, lb.server
+- done as of release 2.1 (IPv6 is fully supported except use of numeric
+ IPv6 address in jobid)
[SNMP] Simple Network Management Protocol (SNMP), Version 3
IETF Standard, for list of related RFCs see http://en.wikipedia.org/wiki/SNMP#RFCs