I just upgraded 2.4.1 to 2.4.8, I Skipped the inbetweens and after this update giganews isnt sending me new headers, anyone know if this is an bug or Am I overlooking something, or perhaps even if giganews Europe is in trouble ?
Ps1. I connect through Giganews Accelerator and did not change anything after the upgrade.. so im a bit lost here.
Ps2. The error UE is giving: "connection unexpectedly closed by server"
Thanks
JR
Can't get new headers (giganews accelerator bug)
i checked the code with servers which don't support compression commands, no problem (checked again right now).
can you test if getting headers works when you don't use accelerator?
do you see errors in the UE error pane next to the headers pane? must be something there.
or maybe firewall blocks this version?
can you test if getting headers works when you don't use accelerator?
do you see errors in the UE error pane next to the headers pane? must be something there.
or maybe firewall blocks this version?
well i just contacted Giganews to see if they have any problems , they tell me they dont.
Heres the part of my acceleratorlog that matters, it goes on and on like this :
7-4-2009 22:31: (152) Server connection starting up
7-4-2009 22:31: (152) Server connection established to 2119-1951
7-4-2009 22:31: (152) Client processing error: Server ended connection: :Y????bBOqZ????.????;^?(?y??O/?,????t???KO`-?J*?XzV`??? ?{)Y????????????????j|????$????@LXKS?BU??B???B????z?o???k??
7-4-2009 22:31: (152) Closing server connection 2119-1951
with my direct connection to Giganews not the localhost so no accelerator no luck either nothing happens I've tested a number of groups.
edit: i made a mistake i did not actually switch my way of connecting back to direct...my bad
Its only a few headers that are getting through at 9 kbps for a few seconds and then it cuts out while thy should be streaming for minutes at 1.83 mbps.
Ill continue to test, its getting a bit late though
Heres the part of my acceleratorlog that matters, it goes on and on like this :
7-4-2009 22:31: (152) Server connection starting up
7-4-2009 22:31: (152) Server connection established to 2119-1951
7-4-2009 22:31: (152) Client processing error: Server ended connection: :Y????bBOqZ????.????;^?(?y??O/?,????t???KO`-?J*?XzV`??? ?{)Y????????????????j|????$????@LXKS?BU??B???B????z?o???k??
7-4-2009 22:31: (152) Closing server connection 2119-1951
with my direct connection to Giganews not the localhost so no accelerator no luck either nothing happens I've tested a number of groups.
edit: i made a mistake i did not actually switch my way of connecting back to direct...my bad
Its only a few headers that are getting through at 9 kbps for a few seconds and then it cuts out while thy should be streaming for minutes at 1.83 mbps.
Ill continue to test, its getting a bit late though
K got it Alex, in properties in the first tab "general"i untagged "support compressed headers [xzver/xzhdr]" that seems to have fixed it.
Perhaps the issue is that the giganews accelerator supports header copression... I'm not into software or programming at all so my knowledge is limited
But if you got more questions just aslk.
JR
Perhaps the issue is that the giganews accelerator supports header copression... I'm not into software or programming at all so my knowledge is limited
But if you got more questions just aslk.
JR
Without accelerator everything works fine, when I check the compression option things work fine again, however I get a big speeddrop en rather erradic network traffic.
As for errors ue did only report an connection unexpectitly closed error strangly enough in my own langage dutch nothing of the sort that you where mentioning.
I already mailed giganews back telling them i found the cause and that it seemed to be compression related, I pointed them to this thread, if they will go here is up to them but i had contact with James "at" giganews "dot" com in case you might want to contact them.
and now Im off to bed
thanks for all the assistance
As for errors ue did only report an connection unexpectitly closed error strangly enough in my own langage dutch nothing of the sort that you where mentioning.
I already mailed giganews back telling them i found the cause and that it seemed to be compression related, I pointed them to this thread, if they will go here is up to them but i had contact with James "at" giganews "dot" com in case you might want to contact them.
and now Im off to bed
thanks for all the assistance
i trimmed the thread short to be on point:
if tonleurs sees two bandwidth readings it means Giganews supports xzlib compression and UE will do just fine by itself.
i verified it now myself, giganews indeed supports those commands just like other providers.
JR: you don't need to use accelerator, it is buggy, use their servers directly with the option checked (then also you'll see both bandwidths in UE). their accelerator is just a mere tool for non-supporting newsreaders, so you'll get exactly the same results.
as to the option i doublechecked it today with zlib docs in addition to tests yesterday before the release, there is no way it is a bug in revised compression headers UE code.
accelerator last version is from december, 2007, there was no xzver command back then. it means something in raw zlib output confuses the accelerator, the output is pure binary stream, maybe it contains some control sequences which they were using for their custom approach and they couldn't expect it to be produced by the newsserver.
i've also updated release notes and the subject of the thread to make all clear.
the reply i got from their support didn't contain any clue, so it took hours to pinpoint the cause for sure with only the help of the users.
in short the matter is closed and we can move on.
if tonleurs sees two bandwidth readings it means Giganews supports xzlib compression and UE will do just fine by itself.
i verified it now myself, giganews indeed supports those commands just like other providers.
JR: you don't need to use accelerator, it is buggy, use their servers directly with the option checked (then also you'll see both bandwidths in UE). their accelerator is just a mere tool for non-supporting newsreaders, so you'll get exactly the same results.
as to the option i doublechecked it today with zlib docs in addition to tests yesterday before the release, there is no way it is a bug in revised compression headers UE code.
accelerator last version is from december, 2007, there was no xzver command back then. it means something in raw zlib output confuses the accelerator, the output is pure binary stream, maybe it contains some control sequences which they were using for their custom approach and they couldn't expect it to be produced by the newsserver.
i've also updated release notes and the subject of the thread to make all clear.
the reply i got from their support didn't contain any clue, so it took hours to pinpoint the cause for sure with only the help of the users.
in short the matter is closed and we can move on.
i thought bit more and now i understand it completely.
given the time frame - last version of accelerator December, 2007 and xzver/xhdr commands - October, 2008 - accelerator cannot be aware of those commands.
from other side the diablo implementation of those commands breaks tradition in a sense, unlike other nntp commands it is not nntp aware proxy friendly (unlike Astraweb implementation).
the truth is if accelerator is not aware about the compression header commands in the diablo version - it cannot process them correctly. most likely it would be able to handle Astraweb implementation as it is or with minimal change, with diablo version it must do zlib inflate in parallel with the client to catch the end of the output, doesn't even sound good.
so maybe accelerator is dead piece of software or if giganews will insist maybe they were running those commands unwittingly (it is just standard diablo option now) and will disable them. if they disable those commands - tonleurs (and others) won't see two speed readings any more and accelerator will stop returning errors.
so the choice it up to giganews (to fix accelerator, to discontinue it or to disable those commands).
given the time frame - last version of accelerator December, 2007 and xzver/xhdr commands - October, 2008 - accelerator cannot be aware of those commands.
from other side the diablo implementation of those commands breaks tradition in a sense, unlike other nntp commands it is not nntp aware proxy friendly (unlike Astraweb implementation).
the truth is if accelerator is not aware about the compression header commands in the diablo version - it cannot process them correctly. most likely it would be able to handle Astraweb implementation as it is or with minimal change, with diablo version it must do zlib inflate in parallel with the client to catch the end of the output, doesn't even sound good.
so maybe accelerator is dead piece of software or if giganews will insist maybe they were running those commands unwittingly (it is just standard diablo option now) and will disable them. if they disable those commands - tonleurs (and others) won't see two speed readings any more and accelerator will stop returning errors.
so the choice it up to giganews (to fix accelerator, to discontinue it or to disable those commands).
accelerator will work.
they just disabled xzver/hzhdr on their server end when they learned those commands cause the accelerator to fail (it happened about 2 days after v2.4.8 release). i couldn't know what they will do that so i recommended not to use the accelerator as long as it worked without it the same well.
so you saw it working for some time without accelerator as long as they had nntp native header compression enabled.
i think it has something to do with marketing, although currently, when it is all supported on nntp level, it looks rather stupid.
the server software build they were apparently running - those commands are only implemented on diablo server - has them enabled by default, most likely they didn't know about it.
good at least they disabled it on their side, i cannot have the option disabled because of giganews accelerator, since header compression works with all other major providers.
they just disabled xzver/hzhdr on their server end when they learned those commands cause the accelerator to fail (it happened about 2 days after v2.4.8 release). i couldn't know what they will do that so i recommended not to use the accelerator as long as it worked without it the same well.
so you saw it working for some time without accelerator as long as they had nntp native header compression enabled.
i think it has something to do with marketing, although currently, when it is all supported on nntp level, it looks rather stupid.
the server software build they were apparently running - those commands are only implemented on diablo server - has them enabled by default, most likely they didn't know about it.
good at least they disabled it on their side, i cannot have the option disabled because of giganews accelerator, since header compression works with all other major providers.
in UE you can add even the same server several times, so if you have 3 connections allowed through accelerator you can add also giganews server again with 17 connections directly, in edit menu->properties->servers you can specify the accelerator proxy only gets headers and the direct server only gets bodies.