UDP API Development

Want to help out? Need help accessing the AniDB API? This is the place to ask questions.

Moderator: AniDB

fahrenheit
AniDB Staff
Posts: 438
Joined: Thu Apr 08, 2004 1:43 am
Location: Portugal

Post by fahrenheit »

I need some clarification and examples:
API Definition wrote:292 NOTIFYGET
{int4 id}|{int4 from_user_id}|{str from_user_name}|{int4 date}|{int4 type}|{str title}|{str body}
i've done some checking and as per the source code of the message send page of myplace, the messages title is limited to 50 chars, the message body is limited to 60 cols * 15 rows = 900 chars are these fixed table values or is just a limit imposed by exp on that specific page?
(i'm asking because fixed values is way better for me than the up to 5000 bytes of the string definition.)
API Definition wrote:293 NOTIFYGET
{int4 aid}|{int4 type}|{str count}|{int4 date}|{str anime_name}
In this context, if count is "count is the number of events pending for this anime " why should't it be a int4 ?
Can someone give an example of a api 293 code, i don't have any pending anime notifies, and would like to know of the possible values of the count thing.
Does the db imposes any kind of char limit to anime titles?

By the way, when checking webaom's latest version (117), i've noticed the use of two extra args in the auth, enc=utf8, and comp=1 and then checked the udp api dev wiki page for info on those, and that arose more questions:

1) as for compression, the api would only use it for replys longer than possibly 1460 bytes, but is the client also able to send compressed commands (i can see some commands where it would be nice to have compression, also for narrow band users it would be nice to have compression support as their udp packets without fragmentation are realy small) and if the client is able to send compressed data, how would we flag it to the api?
1a) couldn't we add some kind of mtu arg to the auth command, example: i'm a modem user, and i got a 576 MTU (less UDP and IP headers), and the API sends 1500 bytes (less UDP and IP headers) packets, i can lose half of API packet, but if the API could compress the packets if they were bigger than the client mtu, we could prevent some packet loss, and following error correction by the client .
2) as for encoding, if one does not pass the enc= arg in the auth command, the api defaults to ascii, right?
2a) also i would give a 202/203 reply code on enconding set to default (203 if client outdated), if encoding requested was not supported, if supported, return the default 200/201.
3) as for the ENCRYPT command, it makes sense only to encrypt the auth command, because of the password, other than that, i don't see any motive to use encryption on the other commands, and why create a new password just for encrypt, use for the md5 string a concat of username+password+salt, that should solve issues without any more fields.
3a) and if the only use of the ENCRYPT command was to pass the auth command without a clear text password, wouldn't it make more sense to set as default password as a MD5 string instead of the clear text version?

Couldn't we extend the NOTIFY command to include buddy support?
API Definition wrote:NOTIFY: Notifications

Command String:
NOTIFY

Possible Replies:
290 NOTIFICATION
{int4 pending_notifies}|{int4 pending_msgs}|{int4 number_of_online_buddys}
501 LOGIN FIRST
That way if we requested a notify command and number_of_online_buddys was more than 0 we could then do a BUDDYLIST to get the status of the users.
(this as just to save 2 packets, as i do a notify to check for messages)

About the flood protection policy, i've been doing something like this, i use short term policy for the first 5 packets then switch for the long term, my question is, can we use short term for 5 packets, then change for long term for 30 seconds, then use short term again for another 5 packets then change again, and so on, or it's short for the first 5 packets and then every other packet sent is long term?

Sorry for the long list, but i do have some questions :P
[edited some times to improve readabilty :P]
epoximator
AniDB Staff
Posts: 379
Joined: Sun Nov 07, 2004 11:05 am

Post by epoximator »

fahrenheit wrote:i've done some checking and as per the source code of the message send page of myplace, the messages title is limited to 50 chars, the message body is limited to 60 cols * 15 rows = 900 chars are these fixed table values or is just a limit imposed by exp on that specific page?
just a limit on site. but i think this limit should be implemented for the udp api too
fahrenheit wrote:In this context, if count is "count is the number of events pending for this anime " why should't it be a int4?
yes, it should be an int
fahrenheit wrote:Can someone give an example of a api 293 code, i don't have any pending anime notifies, and would like to know of the possible values of the count thing.
i can't.. i've never used notifies, and i know it's a bit hard to simulate. but that count isn't really anything to worry about. if two new files were added, then the count should be 2
fahrenheit wrote:Does the db imposes any kind of char limit to anime titles?
max 100 chars in romaji titles (which are returned on 293)

1) no, clients can't send compressed packets atm. but i have nothing against adding this.
1a) ok
2) yes
2a) i guess it would be ok. but the devs should know what they are doing, and the enc= should be hardcoded. if you want to test what's supported use ENCODING
3/a) encryption is not only for hiding the password. i personally do not care too much about it, but some people want it. we could add an alternative way just to hide the password, if that's wanted. about the extra password: dunno really..
fahrenheit wrote:Couldn't we extend the NOTIFY command to include buddy support?
sure
fahrenheit wrote:About the flood protection policy, i've been doing something like this, i use short term policy for the first 5 packets then switch for the long term, my question is, can we use short term for 5 packets, then change for long term for 30 seconds, then use short term again for another 5 packets then change again, and so on, or it's short for the first 5 packets and then every other packet sent is long term?
no. that 5 free packets is only for new connections, meaning the connection has to time out before you can use it again. (at least in theory. it may be possible that what you suggest works, but that doesn't make it right. the flood protection code can be updated/improved at any time to reflect the spec better. on the other hand, no one will blame you for exploiting the system. it just means that i have to get off my lazy ass and fix it)

note that the dev page is for anyone to edit. no one will be shot for making silly requests. i suggest that you add your feature requests yourself. (stuff on that page can and will be implemented before it's moved to the def page, like now, but that doesn't mean it is final.)
exp
Site Admin
Posts: 2438
Joined: Tue Oct 01, 2002 9:42 pm
Location: Nowhere

Post by exp »

fahrenheit wrote:3) as for the ENCRYPT command, it makes sense only to encrypt the auth command, because of the password, other than that, i don't see any motive to use encryption on the other commands, and why create a new password just for encrypt, use for the md5 string a concat of username+password+salt, that should solve issues without any more fields.
3a) and if the only use of the ENCRYPT command was to pass the auth command without a clear text password, wouldn't it make more sense to set as default password as a MD5 string instead of the clear text version?
the problem here is that the anidb database does not store the normal user password in plaintext. this makes it very inconvenient to use hashed passwords for transmittion and impossible to use their plain form for encryption.
the extra api password is stored as plaintext in the database and can therefore be used for all kinds of things. however, the normal authentication does still expect to receive the official password of the user.

on top of that just using a hashed version of the password, would increase the replay attack possibility, not that we're really concerned about that anyway though :P

BYe!
EXP
TheSpawn
Posts: 6
Joined: Tue May 09, 2006 8:17 am
Location: Russia, Moscow, Zelenograd.
Contact:

Post by TheSpawn »

I have one problem. After 5 minute of programming and testing connection to api.anidb.info I was banned... so can you create additional type of connection ? Perhaps on port 9001, where i would n't be banned, but this message will be received.
epoximator
AniDB Staff
Posts: 379
Joined: Sun Nov 07, 2004 11:05 am

Post by epoximator »

no, sorry. just be sure to use one port and not flood. and if you still get banned you have ~30 min, banned time, to find and fix the problem.
TheSpawn
Posts: 6
Joined: Tue May 09, 2006 8:17 am
Location: Russia, Moscow, Zelenograd.
Contact:

Post by TheSpawn »

So, i have one problem.
To Login I'm creating connection throw UDPClient.
connector = New Net.Sockets.UdpClient
Then I'm connecting
connector

Code: Select all

connector.Connect("api.anidb.info", 9000)
After that sending AUTH

Code: Select all

connector.Send(msg, msg.Length)
String of AUTH to send -

Code: Select all

AUTH user=" & LCase(TextBox1.Text) & "&pass=" & TextBox2.Text & "&protover=3&client=anidbinfo&clientver=0&tag=auth"
After that connection is closing.

Code: Select all

connector.Close()
When I want to Logout, I'm open connection, then sending LOGOUT

Code: Select all

LOGOUT s=" & SESSION & "&tag=logout
But always received "501 LOGIN FIRST"

So, where's my fault ?
fahrenheit
AniDB Staff
Posts: 438
Joined: Thu Apr 08, 2004 1:43 am
Location: Portugal

Post by fahrenheit »

well, your problem is that you close your connection, you should close the connection after loggin out not after each command.

also select and reuse a local port, that will save you from trouble up ahead.
TheSpawn
Posts: 6
Joined: Tue May 09, 2006 8:17 am
Location: Russia, Moscow, Zelenograd.
Contact:

Post by TheSpawn »

Big thanks, problem was resolve.
I have not enough practice in Socket programming, but trying to understand it.

So, I'm sorry for my bad English, because, as you can see, I'm not from UK or USA.
Aengus
Posts: 4
Joined: Fri Oct 29, 2004 6:42 am
Location: Saint Petersburg, Russia
Contact:

lid

Post by Aengus »

In the definition of MYLISTADD the following is written: "If you want to change an existing entry and already know it's mylist id (lid) please use the lid-version of this command. It put less load on the server." But MYLISTADD does not return lid, instead it returns only number of entries added. So, to get lid either additional MYLIST, or FILE should be executed, which takes 2 more seconds -- too much, considering that knowing lid by itself is pretty useless.

So, may be it is possible to add lid to the reply of MYLISTADD, at least when only one file is added?
epoximator
AniDB Staff
Posts: 379
Joined: Sun Nov 07, 2004 11:05 am

Post by epoximator »

note that this only happens when using anime + group + epno, but that's not documented (as i can see now). i only added it to make it possible to emulate the chii commands..

the reason it doesn't return lids is because it might result in more than 1400 bytes (although that's not very likely to happen). it was a decision i made without caring too much since i never intended to use it myself. feel free to specify your preferences in detail here and i'll most likely implement it.
Locked