Topic: Azureus XML Parsing

[dolly_oops]

Hi,

I was wondering how GTSdll parses the XML generated by Azureus? The format has changed in 2.4.0.3 betas (though you have had the ability to enable this setting since 2.4.0.0). It seems it might be causing some problems (I'm still trying to figure out whether it is the fault of Azureus or GTSdll).

I could post some XML examples if that would help.

Thanks,
dolly_oops.

[GTS]

Hi,

since dev for 1.x versions is halted, i wont change anything in it, but i'm working on a complete rewrite, so i will prolly put neccessary changes in there

and yes, examples would help

[dolly_oops]

I've put some example XML files here:

http://www.savefile.com/files/7084543

az-a.txt is the "classic" way of generating XML and determining values.
az-b.txt is the new way of generating XML, but using the same way as determining the values.
az-c.txt is the new way of generating XML, and it uses the new way of determining values.

The values here are slightly different, since they were captured at different times (I had to restart Azureus to create az-c.txt)

The output gtsdll seems to output is something like this (reported by an Azureus user):

Code: [Select]

?? BT Totals ?? Dn|Up: 12 Kb/s|12 Kb/s (12 Transfers) ??

It could be the case that some of the new code in Azureus is resulting in the XML being in the values being different, but I don't really see it myself.

If it is something to do with gtsdll handling the XML differently, please let me know. If it is, then I'll do a test for the Host and Referer fields to see if they are both set to www.adv-clan.com - if they are, I'll revert to "classic" XML generation.

If possible, could future releases of GTSdll define a User-Agent field, so I'm able to limit this specialised behaviour only to the current versions of GTSdll?

Of course, this is all assuming that it is your code that has the bug, and not mine...  

Thanks,
dolly_oops.

[GTS]

Looks like its caused by my xml parsing. its really simple done, without any xml library ... it parses it line by line, since the "classic" xml output was easy to parse like that.

It shouldnt be any problem to add User-Agent in future GTSdll releases, but  future GTSdll releases will parse it correctly anyways

as for the Host and Referer fields:

Code: [Select]


on *:sockopen:gtsdll.az.request: {
  if ($sockerr) { echo -a Azureus not running or not configured to work with GTSdll $sock($sockname).wsmsg | return }
  ;echo -s Connected ...
  var %len $calc(85 + $len($ticks))
  .hadd GTSDll_settings az.tmp.header 0
  var %a = sockwrite -n gtsdll.az.request
  %a POST /process.cgi HTTP/1.0
  %a Host: www.adv-clan.com
  %a Referer: www.adv-clan.com
  %a Content-Type: text/html
  %a Content-Length: %len
  %a
  %a <REQUEST>
  %a <METHOD>getDownloads</METHOD>
  %a <REQUEST_ID> $+ $ticks $+ </REQUEST_ID>
  %a </REQUEST>
  %a
  %a
}

As you see, Host and Referer are both set to www.adv-clan.com

I appreciate that you are willing to add special handling for GTSdll, and hope it will not be neccessary too long. Work on GTSdll v2 is progressing slowly unfortunately.

Regards,
GTS.

[dolly_oops]

Looks like its caused by my xml parsing. its really simple done, without any xml library ... it parses it line by line, since the "classic" xml output was easy to parse like that.

I've made some changes on my local copy of Azureus to try and emulate the old-style of formatting (while still keeping the XML/HTTP plugin updates in place). If that's good enough to make GTSdll behave properly again, then I'll detect when requests are made by GTSdll and style it the old way.

The actual data fields are in a different order, but as long as that doesn't matter, we might have a tenative fix in the next beta version - I've got a script which emulates GTSdll's requests to the XML/HTTP plugin, which seems to show my changes work. I'll post some XML in the near future (once the beta is released), and you can check it against that.

I appreciate that you are willing to add special handling for GTSdll.

No problem. Besides, if I don't do it, people will keep blaming Azureus, and I can't have that...  

Thanks,
dolly_oops.

[GTS]

The actual data fields are in a different order, but as long as that doesn't matter, we might have a tenative fix in the next beta version.

I checked my old parsing code, and i think the order shouldnt matter

[dolly_oops]

Right, here's some XML output generated by the latest Azureus beta - do you want to check it works?

http://www.savefile.com/files/8079323

[GTS]

Doesnt seem to work, prolly because u use unix line feed format

[dolly_oops]

Doesnt seem to work, prolly because u use unix line feed format

Argh!

OK, I can probably deal with that. I'll try and submit something for the next beta.

[GTS]

Looks like you fixed it, thats at least what i saw in my channel

[dolly_oops]

Looks like you fixed it, thats at least what i saw in my channel

Yeah... looking at the code after I posted that message, I realised that I hadn't hardcoded Unix line endings after all. I think the text file I uploaded just got converted to Unix line endings since that's the default behaviour of my text editor.

Anyway, glad it's fixed.  

[Rogue`]

Thanks for dropping by dolly_oops and sorting the plugin out, we all know Azureus is a very popular client.