blocklist: err 4

[wonderer]

bit difficult as it is the software generating the error 4 message and there is no packet send to tell there is an error 4

[White Stripes]

wasnt after the packets was after what cache server it happened to be connected to atm... winmx says error4 in its log while the other software has in its log that a connect attempt was made and to where... (the blocklist grab is on a different port so i wouldnt exactly have to sift through scads of data)

[Pri]

It's obvious which cache isn't giving a blocklist because they fail a basic telnet for the blocklist and we already have software to monitor all the caches together at the same time so that we can see which ones are not giving blocklists etc

It's a common issue that parts of the cache software just stops functioning correctly and we have to restart them.

[GhostShip]

Its not that common, however a routine restart ensures any of the caches work in a more stable condition, what doesnt help are the ddos attacks and other anti WinMX stupidity we see, theres always some half wit trying to smash something to make a name for themselves at the expense of us all.

[Pri]

You can't really argue that it isn't common. We've all had to restart our caches lots of times and sometimes when I ran my cache I had to restart it 2 times a day, as did others, and this was before and after the attack which made us patch the cache software. I would often have people PM me to restart my cache because it wasn't working correctly. I just did a scan right now of the caches and found 2 caches that aren't working 100% properly.

I'm not putting the system down I'm just saying that it is a common problem with the software that we have to restart them and that we already have tools to monitor the caches for when things aren't working correctly.

I think it would have been a good idea to add in a basic text file downloading feature to the patch so that if the cache doesn't respond with the blocklist the patch can try the winmxworld webserver to get it over http. I mean it's just a basic thing not to complicated to add and would guarantee everyone has the blocklist. Considering how much importance is placed upon the blocklist working I'm surprised that no one suggested this when it was being made.

[GhostShip]

Well its circlular thing Pri if this site is down the caches dont get the blocklist and they in turn cant hand it out , you see why that wasnt seen as a good idea.

[White Stripes]

if the cache server cant serve it but the site can its not that bad an idea at all... how long is the interval between the err4 timeout and the next grab attempt?

...and shouldnt the cache server(s) have more than one site to grab the blocklist from?

..also... is the use of xmlsoap.org secure?

[Pri]

Indeed that is what I was thinking. Just seems like not a well thought out system to have everything rely on a single site when we all have our own sites and servers that we could host it on as-well.

[White Stripes]

problem with that is -- the patch would most likely need quite a bit of new code...

but decentralization is the best tool the mouse has in this cat and mouse game... ...and a patch 1.1 is about due... one with better error reporting and a little more intelligence such as temporary blacklisting a 'bad' cache server for an amount of time while instantly jumping to the next one to get the blocklist after the fail and blacklist...

[GhostShip]

The world is full of folks with hindsight, I cant remember anyone here making any such suggestions at the time and tbh I wouldn't care if they had as the whole point of having a central point of reference is to ensure the validity and authenticity of the Blocklist.

Sharing the location across many sites is not really a sensible idea, if you had done your homework you would know that the blocklist is shared across 3 sites depending on what patch you use and each of those sites is a community patch partner and thus has a recognised interest in keeping the network safe, the same cant be said for other sites who may or may not misuse the list as folks like Sabre have to block folks they don't like from the network have done so, if this site is down the caches will use the last stored list and we all know in general the changes are in the main minimal for most of the year and the attackers ramp up activity at times like christmas to annoy folks over the holiday period. I don't see any reason to pretend the sky is about to fall in nor any major problems with our current system except ones on paper that are extremely unlikely to occur.

If you want to get into blaming folks for not predicting the future your on the wrong site if however you have new ideas then I,m always willing to listen and discuss the matter with the rest of the staff here, we have never turned our backs on common sense but we have also never turned our backs on the potential for abuse of trust, we have built up this sites reputation over many years as a place mx users can trust and I would not feel happy abrogating any responsibility for the blocklist to other sites.

On the matter of the caches Pri you ran yours as a windows install whereas most of the other operators run linux so perhaps your experience is not mirrored by many of the others, I speak honestly here by saying I,m not aware of any such common issue such as twice daily restarts.

Stripes: There is some activity in the works currently and your ideas will be looked into at implementational level.

[Pri]

You just told me that I didn't do my homework, I think you didn't do your homework as I ran it on Linux just like everyone else on a 1000Mb dedicated rented server running Ubuntu.

You can be very condescending with your 'you didn't do your homework' comments, when we are working off information you are given in this very thread. As an example where you say that the Caches get there blocklist from WinMXWorld.com and having the Patches get there blocklist from this domain directly (under the condition that the caches don't have a copy to give) would be pointless because if the Caches dont have one the site they are getting it from must be down. Specifically I am referring to this comment by you:

Well its circlular thing Pri if this site is down the caches dont get the blocklist and they in turn cant hand it out , you see why that wasnt seen as a good idea.

And no I am not picking on people I never mentioned anyone. What I am saying is that the system does have some issues and yes if I had of been consulted during the creation (I wasn't around at that time to give an opinion anyways) I would have made suggestions like redundancy. You mention that having a central location is better from a security standpoint because then the other people in control of other servers can't meddle with the list of blocked entries. This could be fixed however by simply encrypting the blocked entries in a file that the Caches or Patches download and decrypt. There are many free libraries for basic encryption. Even my own rooms Rentility program downloads an encrypted file to decipher which chat room & remote server it should connect with and begin sending and receiving data. - The reason I'm saying this is because there are ways around all of this stuff.

But regardless of that, if you are trusting people to host cache servers I think you can trust them to redistribute the blocklist without meddling with it or do you not trust the people that you are using for the official WMW caches? Should people be worried that your not confident in the people you have entrusted with this duty? - Again I'm not attacking you I am merely pointing out things you are saying that don't make full sense or are illogical.

You mention in your latest post that 3 separate sites host blocklists. Are you referring to the separate groups that are distributing their own variant of the Community Patch that connects to their websites for the Menubar update notice and their caches or are you referring to something else?

And yeah Hindsight is great - And so is Software we can update software with hindsight, god knows I've updated many of my releases countless times, that is the great thing about software.

[RebelMX]

May i suggest that the patch is modified to allow the primary running patch users to auto distribute their patches blocklist onto other "same patch" users should the caches not be available?  That way the blocklist is not based on that users last online time when the caches were up and running but instead on the communities blocklist? (perhaps even date stamped so that newer lists overwrite older ones?)

This is similar to when the frontcode operated caches went down, those on the network already were able to hold their roomlists open.
Clearly this would require a new write for the patch and a new release, however it would enable the whole network to hold together, and could be set up so that it was secure by ignoring other groups community patches, or even other patches (i.e. the old km patch)

Just a thought...

[White Stripes]

problem with user to user... while it would be a big bandwidth saver and serious redundancy is the way too easy 'man in the middle' attack oppourtunity...

'self checking/healing' cache servers would be a good thing... ..of couse... that means yet more code...

[wonderer]

In my simple view, it is easy, the cache servers get the blocklist from one single point, the list is maintained by one blocklist group.
If the single point is down for whatever reason, the list can not to be updated which is not a big problen seen the frequency updates are needed.
It would be nice however if the cache servers would check eachother to see if the same blocklist is in use. This would solve the problem of a restarting cache server not being able to get the blocklist from the central point in one go.

We are a community so it would be strange if the different patch groups would maintain different blocklists.
The only part where the patches may differ is the default settings and the location of the messege/updatebar.
The last is good to enable every patchgroup to schedule the rollout of a new patch if needed.

 

[White Stripes]

methinks the 3 sites are one blocklist group... no one location but one group... at least thats how it sounds...

..or put another way site 'a' has the same list as 'b' and 'c' and lets say 'a' is suddenly inaccessable... the cache servers could get the list on 'b' and 'c' .... 'b' and 'c' also providing a way to continue communication with the group (a setup thats esp usefull for emergencies)...

[GhostShip]

I have deliberately held back from posting rapidly in this topic as tbh I cant see the need to lay out our entire infrastructural arrangements to our enemies just to satisfy a few users curiosity, you all know me and 99% of you accept my word of honour that the blocklist is both accurate and tightly controlled by a few very trusted colleagues (and proud winmx users) some of whom you probably know but who work in secret to ensure their reports are not tainted with spoon fed attacks aimed at them.

If a few folks are unhappy and post in an annoyed frame of mind then I cant pretend I,m not disappointed with them because I prefer to hear the constructive aspects of their posts rather than be forced to trade unhelpful words that serve no point and deflect us from focusing our attentions on the future and how to improve matters for all, this is done now at  a cross community level, we have striven hard to work together with the other groups and will continue to do so, that's the future, sharing responsibility and working collectively towards a better future for us all in whatever shape that takes, and of course sharing responsibility is also sharing our trust, have we as a community ever got far by acting against each other or instead by working towards a common initiative ?

I am happy with the future we here have chosen and its one of cooperation instead of confrontation, if you have something to offer then its always welcome as it has been since we opened shop here, if the answers your given are not clear enough despite asking bluntly one or two times please take the time to ask yourself why this may be and perhaps seek alternative avenues to obtain the information, there are no real "secret" secrets here but if theres a choice of making attackers work for a living or handing them information on a plate I,m sure you will all agree I should make them work.  

[Lagerlout666]

Lolage big time

Their was a issue with some moron hitting the tcp/udp testing section of the cache software which wasnt set up for dealing with large requests. This was version F. after me going over the code and amending the sections to deal with this pathetic attack G was tested and released.

As for the cache checking page its hardley meant to be treated as gospel. As winmx itself if it finds a port closed/busy will move onto another port or even another dns entry. Which would move you onto another cache.

Ass for this error 4 i am starting to belive that it is possible a cache isnt handling the traffic at peak times of the day. If anyone to blame for this is prob me and i will have a look at maybe lessoning the load in the dns's for some of the home caches. A simple and effective fix but then of course anyone here in this thread who has a spare server to hand is more than welcome to put in for the course.(but i guess that request may make this thread go quite now)

Ill issue a few updates today and hopefully this issue should disapear over the next few days as the dns changes propergate and sorry for being afk and missing this.

[Pri]

Lolage big time

Their was a issue with some moron hitting the tcp/udp testing section of the cache software which wasnt set up for dealing with large requests. This was version F. after me going over the code and amending the sections to deal with this pathetic attack G was tested and released.

As for the cache checking page its hardley meant to be treated as gospel. As winmx itself if it finds a port closed/busy will move onto another port or even another dns entry. Which would move you onto another cache.

Ass for this error 4 i am starting to belive that it is possible a cache isnt handling the traffic at peak times of the day. If anyone to blame for this is prob me and i will have a look at maybe lessoning the load in the dns's for some of the home caches. A simple and effective fix but then of course anyone here in this thread who has a spare server to hand is more than welcome to put in for the course.(but i guess that request may make this thread go quite now)

Ill issue a few updates today and hopefully this issue should disapear over the next few days as the dns changes propergate and sorry for being afk and missing this.

My peercache is up at the IP of this post. 100Mb connection. Feel free to add it to the DNS as before. I am running version F on Windows I don't have version G for Windows only for Linux and I'm not running Linux on my server at the moment.