Do we know what caused this down time?
here's my situation, and it'll sound stupid but let me go.
I was developing an app (well testing the UDP because this is my first solo socket Program, and first UDP program) The day before the downtime I sent the messages, and thought I was not getting responses, however it just wasn't displaying the responses. Now I wasn't hammering the server mind you, I sent a simple message and was waiting up to a minute for a response that didn't come. Shouldn't be a big deal for either of.
However the day later I reexamined my code, and noticed the flaw, fixed it, updated my password and sent it again (using a raw password makes me a bit iffy as well, but that's another discussion) sent the message (an AUTH to make sure I could log in) work up again. and got this response
"505 ILLEGAL INPUT OR ACCESS DENIED"
for which I celebrated my first verified UDP connection, but the message confused me, but I figured I fucked up the order of imputs or something. So I went to check out the website, (about 2 minutes at least had passed a log I have says 5:11PM eastern time was when i got my response but it's definatly unreliable)
Well the story continues that the website was down after the time I wasted, and now I'm sorta feeling like the kid who was playing with the toys and left them out and the father came home and broke his back on something (possibly the toy possibly just fell down the stairs in a drunken stupor) But I just wanted to check what was the chances of us finding out the reason for this down time. Or the possiblity that this could have had something to do with it?
And appologizes about the long winded post it's just hard to explain what I'm feeling. I figure that the UDP should be able to stand this error, but I've also been told by numerous sources the fragility of UDP and so on.. So I'm still a bit worried, if anyone can see a mistake here or in the following line or if this is the problem on the server caused my error I'd like to know so I don't keep thinking I did this.
"AUTH user=kinglink&pass=<clean_plain_text_password_withheld> &protover=0.02c&client=kinglink&clientver=0.0"
Question about current downtime/UDP
Moderator: AniDB
The protover should be 2, and your client ver should be an int as well, but worry not, it's deeply unlikely that it's all your fault for passing a bad parameter. I've chucked all kinds of poo at the UDP API in the past and not killed anidb, so can only assume that exp did his job wonderfully and made it nice and solid. Anyway, as the 'problem' has been growing slowly, it's natural that the UDP (and website) would have been responding earlier on, and it *did* throw the 505 correctly due to your error on the versions.
Rar
Rar
hehe,
don't worry, there is absolutely no way you could have caused this via the udp api. No matter what random junk you would send or in which amounts, the UDP API can handle it.
as was already said:
"AUTH user=kinglink&pass=<clean_plain_text_password_withheld> &protover=2&client=kinglink&clientver=1"
should work.
that stuff about the fragility of UDP you've heard is refering to the connection itself, meaning you can loose data packets of a transmittion. Not to any likely server crashes or stuff like that.
about the password, well, if you login at the website your password will be transfered in plaintext too.
in anidb's setup, where the plaintext passwords are only stored as a hashed version in the database, it is also pretty hard to send anything but plaintext passwords (or obfuscated versions).
I think only an asymmetric encryption with an official puplic key of anidb would help here. And although I like the thought of that, I think it would put too much inconvenience on authors of UDP clients to be worth it.
BYe!
EXP
don't worry, there is absolutely no way you could have caused this via the udp api. No matter what random junk you would send or in which amounts, the UDP API can handle it.
as was already said:
"AUTH user=kinglink&pass=<clean_plain_text_password_withheld> &protover=2&client=kinglink&clientver=1"
should work.
that stuff about the fragility of UDP you've heard is refering to the connection itself, meaning you can loose data packets of a transmittion. Not to any likely server crashes or stuff like that.
about the password, well, if you login at the website your password will be transfered in plaintext too.
in anidb's setup, where the plaintext passwords are only stored as a hashed version in the database, it is also pretty hard to send anything but plaintext passwords (or obfuscated versions).
I think only an asymmetric encryption with an official puplic key of anidb would help here. And although I like the thought of that, I think it would put too much inconvenience on authors of UDP clients to be worth it.
BYe!
EXP
Thank you both, it has put my mind at ease (Even tough the guy who shut down a web site with a single UDP Packet would be a great title)
I figured that the UDP system itself isn't at risk, just the packets but I wasn't sure what might happen with it, as I haven't looked heavily at how the server itself will work.
I'll continue working with the UDP system and see what I can do. Thank you for your time.
I figured that the UDP system itself isn't at risk, just the packets but I wasn't sure what might happen with it, as I haven't looked heavily at how the server itself will work.
I'll continue working with the UDP system and see what I can do. Thank you for your time.