Difference between revisions of "Clients.met file"

From AMule Project FAQ
Jump to: navigation, search
 
Line 24: Line 24:
  
 
*An 8-bits number which specifies the ''cleints.met'' version we're using. [[aMule]] currently supports version ''18'' (''12'' in hexadecimal).
 
*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 [[client]s listed in the file.
+
*A 32-bits number specifying the amount of [[client]]s listed in the file.
  
 
Each [[client]] requires exactly 119 bytes which are organized in the following way:
 
Each [[client]] requires exactly 119 bytes which are organized in the following way:
  
 
*The user's [[FAQ_ed2k#What_is_a_hash?|hash]], which will be exactly 16 bytes long.
 
*The user's [[FAQ_ed2k#What_is_a_hash?|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]].
+
*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]].
+
*The 4 lower bytes of the 8 bytes number which contains the total amount of bytes downloaded from that [[client]] (in [[little endian]]).
*The Epoch (seconds since '00:00:00 1970-01-01 UTC') date when the [[client]] was last identified (requires 4 bytes).
+
*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]].
+
*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]].
+
*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.
+
*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]]]
+
*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.
 
*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 ==
 
== 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 [[client]]s 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 ==
 
== Notes ==

Revision as of 22:57, 9 March 2005

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).