Recomendations
DavidXanatos (Talk | contribs) m (→Packet Format: I assume thats how the entries start/end) |
(Using official opcodes) |
||
| Line 24: | Line 24: | ||
Bit number 2 shows if some recommendations (at least one) are available. This is evaluated in case we want to request the list from someone. (this is rather cosmetic but should save some overhead). | Bit number 2 shows if some recommendations (at least one) are available. This is evaluated in case we want to request the list from someone. (this is rather cosmetic but should save some overhead). | ||
| − | The request and answer | + | The request has to be sent over OP_ASKSHAREDFILESDIR (OP_OP_EDONKEYPROT) asking for a special directoy (L"*Recommendations* suggested) and sending the answer via OP_ASKSHAREDFILESDIRANS (OP_OP_EDONKEYPROT). This has the advantage that no additional opcode has to be used and the code is nearly completely available in the official client already. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
= Packet Format = | = Packet Format = | ||
Revision as of 09:08, 27 July 2007
THIS IS NOT FINAL... If you have any suggestions please post them on the discussion page
Contents |
Introduction
The recommendation system is thought to enhance the filesharing experience. While most ppl do not offer their list of shared files or do not want to show all files on it or even want to promote files they aren't sharing any longer recommendations will provide a useful addition.
Features
The current recommendation system includes:
- manual adding of currently shared/downloading files, search results and ed2k-links to the recommendation list
- possibility to manually (de-)select if a recommendation gets shared
- AICH hash support
- comment support
- rating support
How it works
Recommendations are kept in a separate editable list (preferably with a listctrl in sharedfileswnd). The recommendation support has to be announced via ModProt and uses 2 bits. Bit number 1 shows if recommendations are supported. This is evaluated in case someone wants to request our list of recommendations and in case we want to request the list from someone. Bit number 2 shows if some recommendations (at least one) are available. This is evaluated in case we want to request the list from someone. (this is rather cosmetic but should save some overhead).
The request has to be sent over OP_ASKSHAREDFILESDIR (OP_OP_EDONKEYPROT) asking for a special directoy (L"*Recommendations* suggested) and sending the answer via OP_ASKSHAREDFILESDIRANS (OP_OP_EDONKEYPROT). This has the advantage that no additional opcode has to be used and the code is nearly completely available in the official client already.
Packet Format
The recommendation request is an empty packet with the OP_RECOMMENDATIONS opcode. The recommendation answer will be sent in any case, even if there are no recommendations available. That way only ONE opcode is used. The packet will look like that (adapted from official code):
[uint32 4] //filecount // file 1 [hash128 16] //filehash [uint32 4] //our ID - only if useful* [uint16 2] //our Port - only if useful* [uint32 4] //taglist size ** <taglist> //variable size depending on which tags are to be sent includes: * filename //FT_FILENAME * filesize //FT_FILESIZE * filerating //FT_FILERATING * filecomment //FT_FILECOMMENT can include: * filetype //FT_FILETYPE * metadata //FT_MEDIA_ARTIST,FT_MEDIA_ALBUM,FT_MEDIA_TITLE,FT_MEDIA_LENGTH,FT_MEDIA_BITRATE,FT_MEDIA_CODEC ... // file n
* we are useful if we are connected, not firewalled and do currently share the recommended file ** it would be possible to cut that down to a uint8 (1 byte) to save overhead because it's extremely unlikely that we will ever need more than 255 tags
This format is kept for now so we can easily process the resulting packet using the ProcessSearchAnswer function which is already available in the official client.
