User:Ommina

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 271-274 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.

Notification Packet Format

New File Notify:

 271 {int4 notify_packet_id} NOTIFICATION
 {int4 relid}|{int4 date}|{int4 count}|{str relname}|{int2 reltype}|{int2 priority}

• relid is the id of the related entry (anime, group)
• date is the time of the event (in seconds since 1.1.1970)
• count is the number of events pending for type
• relname is the name of the related entry
• reltype is: 1 = anime, 2 = group, 3 = producer
• priority is: 0 = low, 1 = medium, 2 = high

Note	Group (and producer) related file notifications are not implemented yet.

New Private Message Notify:

 272 {int4 notify_packet_id} NOTIFICATION
 {int2 type}|{int4 date}|{int4 sent_by_uid}|{str sent_by_name}|{str subject}|{str body}|{int mid}

• type is the type of the message (0=normal msg, 1=annonymous, 2=system msg, 3=mod msg)
• date is the time the message was sent (in seconds since 1.1.1970)
• senderuid/sendername are the user id and username of the sender
• subject is the message subject
• body is message body (can be truncated)
• mid is message id and can be used with NOTIFYACK

Buddy Event Notify:

 273 {int4 notify_packet_id} NOTIFICATION
 {int4 buddy uid}|{int2 event type}

• Possible event types:
  • 0 => LOGIN
  • 1 => LOGOUT
  • 2 => ACCEPTED
  • 3 => ADDED

Going Down Event Notify:

 274 {int4 notify_packet_id} NOTIFICATION
 {int4 time offline}|{int4 comment}

• Clients with any notification on will receive the GOINGDOWN message before the API goes offline.
• Time offline is the time in minutes the API will be down, 0 if indefinite (client can direct user to the AniDB site for status updates).
• The comment is a short explanation for the downtime.
• Only one datagram will be sent, and the server will not listen for replies.

---

PUSHACK: UDP Notification Acknowledge

Used to acknowledge notification packets (271-274). A client must be prepared to issue this command before using PUSH.

Command String:

• PUSHACK nid={int4 notify_packet_id}

Possible Replies:

• 280 PUSHACK CONFIRMED
• 380 NO SUCH PACKET PENDING

Info:

• See: PUSH

---

CALENDAR: Get Upcoming Titles

Returns the anime ids of the next ten anime due to be aired / released, ordered by start date.

Command String:

• CALENDAR

Possible Replies:

• 297 CALENDAR

{int aid}|{int startdate}|{int dateflags}/n

..repeated nine times

• 397 CALENDAR EMPTY

Info:

• Takes no parameters (other than the session string)
• Titles returned are filtered by the 'show adult' preference of the logged in user. That is, users who have elected to hide adult content will have it hidden here as well.
• Date flags are used to indicated an unknown value (unknown month, unknown day)
• dateflags values: [Look them up]

REVIEW: Get Anime Review

Retrieves the review scores and text for an anime review. Like ANIMEDESC, it will likely take multiple calls to this comment to retrieve a complete review - almost all reviews will overflow the size limits of a UDP packet.

Command String:

• REVIEW rid={int4 id}

Possible Replies:

• 234 REVIEW

{int4 current part}|{int4 max parts}|{int4 review id}|{int4 author uid}|{int4 score_animation}|{int4 score_sound}|{int4 score_story}|{int4 score_character}|{int4 score_value}|{int4 score_enjoyment}|{str review_text}

• 234 REVIEW

{int4 current part}|{int4 max parts}|{str review_text}

• 334 NO SUCH REVIEW

Info:

• IDs and scores are returned with part zero only. Parts one through max exclude the scores and return the text block only.

[Maybe exchange author uid for author name. Or a uid->name lookup via USER?]

Empty Table

Byte 1
Bit	Decimal	Data Field
0	1	String
1	2	String
2	4	String
3	8	String
4	16	String
5	32	String
6	64	String
7	128	String