Clients.met file

From AMule Project FAQ
Revision as of 18:54, 11 January 2011 by Reorder (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

File

Name: clients.met

Location: ~/.aMule/

Description

This file stores the credits which our client owes other clients.

Format

Previous notes

First of all, have in mind that if there is absolutely anything in this file which doesn't strictly follow it's format rules, the whole file is discarted automatically. So be very carefully when messing around with it.

Also, if the file's version doesn't exactly suit the client's supported version (the client should only support one single version), the whole file will also be discarted.

All numbers in this file are stored in little endian.

Into the format

The format goes as follows:

  • An 8-bits number which specifies the cleints.met version we're using. aMule currently supports version 18 (12 in hexadecimal).
  • A 32-bits number specifying the amount of clients listed in the file.

Each client requires exactly 119 bytes which are organized in the following way:

  • The user's hash, which will be exactly 16 bytes long.
  • The 4 lower bytes of the 8 bytes number which contains the total amount of bytes uploaded to that client (in little endian).
  • The 4 lower bytes of the 8 bytes number which contains the total amount of bytes downloaded from that client (in little endian).
  • The Unix Epoch (seconds since '00:00:00 1970-01-01 UTC') date (stored in little endian) when the client was last identified (requires 4 bytes).
  • The 4 higher bytes of the 8 bytes number which contains the total amount of bytes uploaded to that client (in little endian).
  • The 4 higher bytes of the 8 bytes number which contains the total amount of bytes downloaded from that client (in little endian).
  • Two bytes which are set to anything, since they are reserved for future use in future specifications of the file.
  • A 1-byte number which specifies the size of the client's SecureIdent public hash
  • Now the SecureIdent hash is placed. It must occupy 80 characters, so if it requires less than 80 characters, the rest must be filled with random data.

Example

Here follows a valid clients.met file and, right after each field, an explanation of it's contents. Please note that the file's contents are shown in hexadecimal values and all bytes have been separated from each other to make more readable:

12 <- Version 0x12
02 00 00 00 <- 2 clients will be listed. This number is in little endian
00 00 00 00 00 0F 00 00 00 00 00 00 00 00 6F 00 <- The client's hash
00 00 00 00 <- The 4 lower weight bytes of the total amount of bytes we have uploaded to that client (in little endian).
12 F2 01 00 <- The 4 lower weight bytes of the total amount of bytes we have downloaded from that client (in little endian).
BF 29 12 42 <- The Unix Epoch date stored in little endian. The decimal value of the hexadecimal value 0x421229BF is 1108486591, which is this date: Tue, 15 Feb 2005 17:56:31 +0100
00 00 00 00 <- The 4 higher weight bytes of the total amount of bytes we have uploaded to that client (in little endian).
01 00 00 00 <- The 4 higher weight bytes of the total amount of bytes we have downloaded from that client (in little endian).
4E 65 <- Just tandom data. This two bytes are reserved.
38 <- This client's SecureIdent public hash is 56 (0x38) bytes long.
F4 69 E7 27 34 D7 6A 2F 74 E7 C2 CE E5 89
43 65 BB 26 73 24 83 DC 3A 2E 84 24 7A E3
89 73 E7 8F 78 C7 86 9D 69 E7 8A 90 8B 89
07 B7 8C 87 E8 79 D4 F8 76 A9 E7 C7 D8 9A <- The client's publich hash
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 0A 00 00 10 11 64 F4 00 00 00
FA EE E4 00 00 00                         <- Just random data to fill the 80-56=34 left bytes for this client.
00 00 00 00 00 0F 00 00 00 00 00 00 00 00 6F 00 <- The other client's hash
... <- Here would follow the other client's data...

The total downloaded and total uploaded bytes amount is calculated this way:

  • Total Uploaded = Total_Uploaded_High_Bytes x 2^32 + Total_Uploaded_Low_Bytes
  • Total Downloaded = Total_Downloaded_High_Bytes x 2^32 + Total_Downloaded_Low_Bytes

In the above example, the total uploaded and downlaoded amount would be (remember, the numbers are stored in little endian, so you have to inverse their order):

  • Total Uploaded = 0x00000000 x 2^32 + 0x00000000 = 0 Bytes
  • Total Downloaded = 0x00000001 x 2^32 + 0x0001F212 = 4294967296 + 127506 = 4295094802 Bytes = ~4 GigaBytes

Notes

If the backup file (clients.met.BAK) is larger than the current clients.met file, the backup file will not be overriden.

Credits expire when 12960000 seconds (150 days) have passed without seeing that client.

Almost 4,300 million clients can be stored in this file (enough, isn't it?)

Each client is 952 bits (119 bytes) worth ;-)

The maximum size allowed for this file is around 475 GigaBytes (which is way larger the size most filesystems allow for a single file).

Version

Created by "Unknown User" on 09.03.05 at 23:16
Updated by Vollstrecker on 23.01.08 at 18:48