GMTI Generator: packet splitting almost done

Today I was working on packet splitting in GMTI Generator and (ta-ta!) it is working! Right now it assumes that dwell segment comes as last in the GMTI packet, but I guess this is the standard way, approved by the community earlier. So far it hasn't been tested too much, I'm going to do it tomorrow.

The other thing that need to be done is re-designing the way the GMTI packets are displayed and handled. Right now, I'm using simple solution: I'm taking the GMTI packet, convert is to XML (the method was already there) and then display it in the JTree. The way as it is right now requires lots of object->XML conversions and is not very robust and memory efficient; I have put it in there only because I was too lazy to write a proper tree renderer :-). This needs to be changed right now.

new version of CSD thick client

Some people requested some data from CSD, as it turned out it was ~22k GMTI files. Our CSD Thick client (filepuller app) was not working correctly, so I made some changes that (I hope) will make it work better. I've changed the way y which the BQS query string is read from the configuration file, it wasn't dealing properly with strings that included special (> < etc.) characters.

Also, I've added command line argument checking routine (now we are using two parameters, one for alternate config file and the other for "dry-run" option, one that does perform the query but does not download the files. The organisation of FilePuller class changed slightly: I have moved some parts of the code to separate methods (for better control over error handling). The main() function was also moved from FilePuller.cc to separate file (this is I think better to separate calls to the objects from classes themselves).

I will post the new version of filepuller app on the portal shortly.

technical details of SSR after TIE'05

I've just come back from interesting discussion between Reiner, Arne and David on (future) "MAJIIC Jabber Implementation Guide" document that David is working on. We agreed on how the Jabber <iq> messages should be exchanged during the course of "SSR coversation". Also, we agreed that there should be some mechanism for querying if a user running under certain resource can grok SSR at all (preferably with some additional information, like schema version number), similarly like it's done in JEP-0065 for SOCKS5 file transfer, using Service discovery (described in JEP-0030).

Arne proposed a different approach to the whole SALT/SSR sending: XML-RPC but as no-one had any first-hand experiences with it, we decided to stick to IQ messages (besides, lots of non-standard Jabber protocols and extensions are using IQ).

So, what we've agreed upon? It is really pre-draft, we will follow the this schema: SSR initial request will be embedded in < iq type="get">, and the rest in <iq type="set"> ("get" type will act as a signal for SSR jabber client that new SSR has just arrived). After each of abovementioned <iq> messages, the receiver should send empty response <iq type="result">.

We also all agreed upon that this discussion should occur before the TIE. I hope that we will be able to stick to that and get it ready before SIMEX'06.

further SSR plugin testing on TIE'05

After yesterday's lack of success I felt pretty concerned about how I can solve the problem with SSR plugin being unable to speak correctly with other SSR systems. Namely, I had problems with receiving SSR ack's from NORCCIS. Then I looked at IQ header and discovered, that they were sending it with type="set" - and the plugin was looking for type="result"... after fixing that we were able to communicate, although there were some problems in the beginning (I really can't say what they were, tho).

I've started adding some fuctionality required by some participants: they wanted to be able to track back received and sent SSRs. Right now I have a simple dialog with table in it, with 2 columns: one for timestamp, second for SSR. User can click on the row of this table to view the SSR, in the same way as they are shown when they are composed.

TIE'05 and SSR problems

It is beginning of 2nd week of TIE and I haven't written anything that was going on, mostly because of lack of time (and spirit...). Anyways, today was a very long and exhausting day (again) but I managed to get some more understanding on how the XML communication works. The plan was to get the JBother's SSR plugin talk to other systems. NORCCIS was one of them, and I noticed that the data was not comming through - they were claiming that the SSR are not appearing there.

First of all, I took a look at the XML SSR plugin was generating - thanks to Ronald's piece of code I was able to run the schema accordance test and discovered that some elements were plainly wrong: nillable instead of non-nillable, using wrong units ('kilometers' vs. 'meters'), wrong string for ID tags (apparently, they cannot start with a numeral). After making sure that the XML code we were generating was OK, I took a look at XML sent by other system. It turned out that they were using namespaces "embedded" with tags - not presented in the "header" of the file. This, in connection to XmlPullParser hack we are now using to, basically, copy over the XML for XMLBeans to do the parsing itself, resulted in wrong namespaces when parsing. This has been corrected, however - it did not help the fact that NORCCIS was not seeing the stuff from us.

I've worked some time on whitespace issue - right now the plugin sends XML without it, to satisfy the NORCCIS guys - but I don't think this is good. Whitespace shouldn't matter with XML. Well, we'll leave it to after-exercise, esp. because there will be cross-cueing test tomorrow.

In the process, we've discovered a bug in NORCCIS code: whenever it was sending acknowledgements, they were presented as regular request (this has been verified by ethereal's snooping on the network). JBother resulted in displaying improper window in this situation. When JBother was sending ack's, NORCCIS reported to see them correctly.