@mas wrote:
Hmmm, no problems here with RSP. Well only 1/4 of his # of songs but still *4 time wouldnt be a big problem.
Is RSP much faster than DAAP or does it simply not scale linear?
It’s much faster.
Two things wrong with daap:
1. the data blocks it sends back aren’t optimized for… well… anything. It’s a binary xml format, only with just start tags and a block length, and no end tag.
So to send a string, like song artist, the atom looks like:
Or:
asar 9 “The Smiths”
That’s fine, but you can’t start streaming the data until you know the size. For a song title, that’s fine, but the song artist is just one data block that’s contained in another block: a mlit (dmap.listingitem) block. So you have to have the size of *all* the metadata for the whole song so you can calculate the size of the listingitem so you can send that atom. Except the listingitem is one of several listingitems in a mlcl (dmap.listing) block, which is one of several blocks in a adbs (daap.databasesongs) block.
So you have to calculate the length of all the metadata of all the items in the database before you can send a single byte of the response.
So that’s one pass through the database to calculate the size of the resulting block of data, then another pass to actually build the block and send it.
Then you can’t really compress it either, because you have to know what the exact data is you are going to compress since the only type of connection iTunes supports is a persistent one. So to send the data compressed, you need three full passes through the database.
Blech.
RSP, on the other hand, just uses straight xml and non-persistent connections, so it can return the whole library and compress on the fly on a single database pass. Much faster.
Also, xml compresses better than daap, so the wire sizes are smaller as well.
So the upshot is that rsp is faster, more ajaxy, and generally more suited to embedded devices.