358
edits
UDP API Definition: Difference between revisions
→Getting Notifications
| Line 287: | Line 287: | ||
{{eyecatch|Note|The ID supplied by NOTIFYLIST will be the ID of the affected notification type. Since, at present, only the anime type is supported, this value is always an aid. In the future, it may represent a group or producer ID. In these cases, the str '''type''' value will indicate what entity the ID represents.}} | {{eyecatch|Note|The ID supplied by NOTIFYLIST will be the ID of the affected notification type. Since, at present, only the anime type is supported, this value is always an aid. In the future, it may represent a group or producer ID. In these cases, the str '''type''' value will indicate what entity the ID represents.}} | ||
'''Method Two: Server PUSH''' | |||
With this method, the server takes the active role in advising the client that a new file has arrived. The client must register with the server to receive further advice information, and will be responsible for keeping the login session from timing out, and any NAT router ports open. The UDP packet is sent to the ip and port from which the AUTH command was received. | |||
This method compensates for the disadvantages of the polling method, but is more difficult to code. Blocking sockets are no longer an option, nor can a client make any assumptions that an incoming packet will necessarily be a reply to the last command sent. The tag option may be helpful here. | |||
A PUSH HOWTO: | |||
* PUSH to register your client session. | |||
* Listen for 720-799 NOTIFICATIONs ('''not 290'''). | |||
* Use PUSHACK to to acknowledge the notification using the nid supplied with NOTIFICATION | |||
* Use NOTIFYGET to receive a notification, suppling the relid provided by NOTIFICATION (NOT the packet ID) | |||
* Use NOTIFYACK to acknowledge a notification, suppling the relid provided by NOTIFICATION (if desired) | |||
* Use UPTIME (with an interval between 30 and 35 minutes) to keep login session valid | |||
It is probably a good idea to use tags to separate NOTIFICATIONs from the other communication. NOTIFICATIONs will '''never''' have tags. | |||
=== PUSH: UDP Notification Registration === | |||
Register your client as an observer for AniDB notification events for the current user. If you are registered for one or more event types the AniDB server will send an UDP packet (format see below) on each change which affects the current user. | |||
'''Command String:''' | |||
* PUSH notify={boolean on_new_file}&msg={boolean on_new_private_message}[&buddy={boolean on_buddy_event}] | |||
'''Possible Replies:''' | |||
* 270 NOTIFICATION ENABLED | |||
OR (if both values are 0) | |||
* 370 NOTIFICATION DISABLED | |||
'''Info:''' | |||
* A client which has registered to receive UDP notification packets must: | |||
** Issue a PUSHACK command for each notification received with ''notify_packet_id'' provided in the notification packet. | |||
** Use PING to keep the connection alive (< 30 min). | |||
** Use UPTIME to ensure that the session is OK (>= 30 min). | |||
* Every notification generated is resent 3 times unless acknowledged. After that the client is logged out. | |||
=== NOTIFY: Notifications === | === NOTIFY: Notifications === | ||