docs/OpenFT.txt

   1 Open FT Packet:
   2
   3 {
   4 int16 len;
   5 int16 opcode; | FT_PACKET_COMPRESSED : si le paquet est compresse
   6 char[] data;
   7 }
   8
   9 *******************************************************
  10 IP:
  11 int16 4  /* IPv6 */
  12 int32 IP
  13 int32 0
  14 int32 0
  15 int32 0
  16
  17 *******************************************************
  18 opcodes:
  19 {
  20         /* AUTHENTICATION AND HANDSHAKING */
  21
  22         FT_VERSION_REQUEST = 0,
  23 {
  24 }
  25         FT_VERSION_RESPONSE = 1
  26 {
  27 int16 OPENFT_MAJOR
  28 int16 OPENFT_MINOR
  29 int16 OPENFT_MICRO
  30 }
  31         FT_CLASS_REQUEST =2
  32 {
  33 }
  34         FT_CLASS_RESPONSE = 3
  35 {
  36 int16 node_class; /* NODE_PARENT/NODE_CHILD/NODE_SEARCH */
  37              NODE_NONE   = 0x00,
  38              NODE_USER   = 0x01,
  39              NODE_SEARCH = 0x02,
  40              NODE_INDEX  = 0x04,
  41              NODE_CHILD  = 0x08,        /* node is sharing files to 'self' */
  42              NODE_PARENT = 0x10,        /* node has 'self' files shared */
  43 }
  44         FT_NODEINFO_REQUEST = 4
  45 {
  46 }
  47         FT_NODEINFO_RESPONSE = 5
  48 {
  49 IP     0
  50 int16  port
  51 int16  http_port
  52 }
  53
  54         FT_NODELIST_REQUEST=6,
  55 {
  56 }
  57         FT_NODELIST_RESPONSE,
  58 {
  59                                                  NULL
  60         ft_packet_send (c, FT_NODELIST_RESPONSE, "+I%hu%hu",
  61                         response->ip, response->port, response->class);
  62 }
  63
  64         FT_NODECAP_REQUEST=8,
  65 {
  66 }
  67         FT_NODECAP_RESPONSE,
  68 {
  69 }
  70
  71         FT_PING_REQUEST=10,
  72 {
  73 }
  74         FT_PING_RESPONSE,
  75 {
  76 }
  77
  78         /* SHARE NEGOTIATION AND STATS */
  79
  80         FT_CHILD_REQUEST   = 100,
  81 {
  82 int16   TRUE;
  83 }
  84         FT_CHILD_RESPONSE,
  85 {
  86 int16 response (TRUE or FALSE suivant que le noeud est accepte comme fils)
  87 }
  88
  89         FT_SHARE_REQUEST, 102
  90 {
  91         ft_packet_send (c, FT_STATS_REQUEST, "%hu+I%lu%lu",
  92                         2 /* submit digest */,
  93                         NODE (child)->ip, shares, (unsigned long) size);
  94 }
  95         FT_SHARE_RESPONSE,
  96 {
  97 }
  98
  99         FT_MODSHARE_REQUEST, 104
 100 {
 101 }
 102         FT_MODSHARE_RESPONSE,
 103 {
 104 }
 105
 106         FT_STATS_REQUEST, 106
 107 {
 108 }
 109         FT_STATS_RESPONSE,
 110 {
 111  ft_packet_send (c, FT_STATS_RESPONSE, "%lu%lu%lu",
 112                                                         users, shares, (unsigned
 113  long) size);
 114 }
 115
 116         /* SEARCHING */
 117
 118         FT_SEARCH_REQUEST  = 200,
 119 {
 120 }
 121         FT_SEARCH_RESPONSE,
 122 {
 123                 ft_packet_send (c, FT_SEARCH_RESPONSE, "%lu", P_INT (id));
 124                 ft_packet_send (c, FT_SEARCH_RESPONSE, "%lu+I%hu%hu%lu%lu%s%s",
 125                                 P_INT (id),
 126                                 share->host_share->host,
 127                                 share->host_share->port, share->host_share->http
 128 _port,
 129                                 share->host_share->availability,
 130                                 file->size, file->sdata->md5,
 131                                 (file->sdata->hpath ? file->sdata->hpath : file-
 132 >sdata->path));
 133         }
 134 }
 135
 136         /* DOWNLOADING */
 137
 138         FT_PUSH_REQUEST    = 300,
 139 {
 140         ft_packet_send_indirect (ip, FT_PUSH_REQUEST, "+I%hu%s%lu%lu",
 141                                  NODE (c)->ip, NODE (c)->http_port,
 142                                  request, start, stop);
 143 }
 144         FT_PUSH_RESPONSE
 145 {
 146 } ft_packet_send_indirect (search_ip, FT_PUSH_RESPONSE, "+
 147 I%hu%s%lu%lu",
 148                                                  ip, port, request, start, stop)
 149 ;
 150
 151 };
 152
 153 NOTE: this file is basically what OpenFT was supposed to be before it
 154 started...what it is now is probably different :)
 155
 156                                     OpenFT
 157                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 158
 159
 160 TECHNOLOGY OVERVIEW
 161 -------------------
 162
 163 OpenFT is an open source implementation of a distributed peer to peer file
 164 sharing network.  It is similar in design to gnutella with significantly
 165 improved scalability based on a concept of hierarchal node classification.
 166 This node classification is determined by each individual node based on the
 167 resources that node has to donate to the Free Transport network (FT).  The
 168 advantage of OpenFT over other major networks (such as KaZaa) is that we do
 169 not require authentication on a centralized network.
 170
 171 Another key feature of the OpenFT network is that search results and share
 172 submission transactions will be compressed with the GZ compression technology.
 173 This is done to allow speedy search results and submissions into the network.
 174
 175
 176 NODE CLASSIFICATION
 177 -------------------
 178
 179 OpenFT's node classification system is designed in such a way that each higher
 180 level classification inherits the responsibilities of all lower node
 181 classifications.  For example, a user node that has connected to the network
 182 for the first time (explained later) will receive a list of search nodes upon
 183 request.  At any later time if that node promotes to a search node itself, it
 184 will still maintain the connections with those search nodes that it once held
 185 as a user node for two main network goals.  One is that if the person using
 186 the search node machine wishes to request a search themselves (remember they
 187 are still maintaining the functionality of a user node), they will use the
 188 node connections that all user nodes maintain.  The sceond feature this allows
 189 for is that all connecting user nodes may request a search and have that list
 190 of supernodes returned to them, thus recursing the system to a user-defined
 191 depth.
 192
 193 Every node is expected to maintain a list of (and/or connections to)
 194 supernodes at all times.  The client default will be set at 25.  This
 195 functionality is not reduced when that node is promoted to a supernode or even
 196 an index node, responsibilites are only added, not removed.  All nodes must
 197 also be responsible for maintaining a relatively large index of all user and
 198 supernodes for reference when they need re-entry back into the network (as to
 199 avoid using index nodes if at all possible).
 200
 201
 202 USER NODE
 203 ---------
 204
 205 User nodes can be considered the "base" node classification for the entire
 206 network.  User nodes generally only make outgoing connections to search nodes
 207 and perform searches as well as maintain lists of nodes that have passed
 208 through them (client default is set to a maximum of 100), however on initial
 209 connection into the network they have a few more responsibilities.
 210
 211 The first of these is that they must be hardcoded for a list of default search
 212 and index nodes.  They will immediately spawn connections to each node on the
 213 static list and attempt to replace them with the node links provided by the
 214 new connections.  This is a critical first-time operation as relying on
 215 hardcoded servers forces each client release to be reliant on a static set of
 216 IPs.  It's important that this dependancy be broken as soon as possible by the
 217 client and begins maintaining its own references into the network.
 218
 219 Regular user nodes must also submit their list of shares for storage (and
 220 hashing) to any outgoing search node connections that are established from the
 221 known network references.
 222
 223
 224 SEARCH NODE
 225 -----------
 226
 227 Search nodes can easily be considered the "backbone" of the entire network.
 228 They are responsible for handling incoming connections from user nodes (yes,
 229 this means you MUST be exposed to the Internet directly) that supply a
 230 compressed list of files.  For scalability purposes, the client default will
 231 be set to maintain a list of only 300 users per search node.  This allows the
 232 search node machine to operate on the OpenFT network with as minimal overhead
 233 as possible.
 234
 235 Any user node across the entire network may at any time spawn a connection to
 236 a search node and request that it hash it's internal list of files and return
 237 results accompanied with the ip:port of the user (port being 0 if the user is
 238 firewalled, see FIREWALLED USERS).  Prior to this operation however, search
 239 nodes respond with it's list of search nodes (maintained at 25 by default) as
 240 to instruct the user where it can optionally find more search results if
 241 required (defaults to attempting up to 100 search node connections).  This
 242 system allows search nodes to only ever have to handle the traffic generated
 243 by their shared list and thus does not require any form of tunnelling of
 244 search results, which would result in wasted network load if the user himself
 245 can request the same operation from the search node.
 246
 247 Search nodes also have an extra advantage over user nodes in maintaing a
 248 robust list of search nodes (again, for re-entrance into the network) as they
 249 will optionally request the search node list from any incoming user node
 250 connection.  As a result of this advantage, search nodes will maintain lists
 251 of new search nodes and will flush them every 5 minutes (default) while
 252 sending them down to all connected user nodes.
 253
 254
 255 INDEX NODE
 256 ----------
 257
 258 The final and probably least important node classification is that of the
 259 semi-static index node.  These nodes are not automatically determined by the
 260 network or the client but are selected on a reviewed opt-in basis.  These
 261 nodes will maintain an unlimited list of all seen supernodes and will
 262 regularly communicate with search nodes when a new promotion has occurred (so
 263 that it can now list them).  These nodes are also referenced for "lazy" nodes
 264 who do not have any pre-determined network references left alive.
 265
 266
 267 CLASS PROMOTION
 268 ---------------
 269
 270 Promotion is still a very vague subject in the OpenFT implementation.
 271 Currently our line of thinking is leading us towards a semi-trusted system
 272 where the client daemon will monitor simple data about the user node.  Mainly,
 273 the avg, high, and low k/s reported by this user both incoming and outgoing.
 274 If the usage hits a pre-determined thresh-hold the node will make a request to
 275 all connected supernodes that it has now received a promotion.  All search
 276 nodes aware will connect to their respective search and index nodes with a
 277 simple message indicating a new supernode IP.  The user node undergoing
 278 promotion will then request that any 5 search nodes connect back to verify
 279 connection speed and the ability to bind outgoing internet ports (ie not
 280 firewalled).  It is still undecided but quite likely that the client will be
 281 trusted to perform an internal list hashing test to insure that it indeed can
 282 handle the load of the configured user count.
 283
 284
 285 FIREWALLED USERS
 286 ----------------
 287
 288 Users that do not have access to a direct internet connection (by way of a NAT
 289 machine or otherwise) will _NOT_ be allowed to become search nodes but will
 290 still operate fully on the network.  Their only limitation is that they will
 291 not be able to download from another firewalled user (the only other way
 292 around this would be to tunnel data via supernodes which has been determined
 293 that it stresses the network too much to be practical).
 294
 295 Indirectly connected users may still upload files by a push upload system
 296 implemented in conjuction with the search node.  Clients are expected to store
 297 the search node that returned each result so that upon download request that
 298 node can be contacted and asked to deliver a message to the node required for
 299 uploading.  That supernode will return an error message back if unable to
 300 contact the given node, otherwise will return nothing.  If the user node in
 301 question is behaving properly it will make an outgoing connection to the
 302 downloading node and will then proceed to push the requested file (after a
 303 brief header describing the nature of the operation, as is standard for all
 304 communication delivered to a user node directly).
 305
 306
 307 DOWNLOADING
 308 -----------
 309
 310 Downloads are divided among all hosts that have matched the same md5sum from a
 311 search result.  In order to prevent poisoned files from corrupted the whole a
 312 preliminary size and offset is calculated by the downloading agent and
 313 requests those offsets from each host.  The data segment matches from the
 314 majority of hosts is accepted to be the true file.
 315
 316
 317 CONTACT INFORMATION
 318 -------------------
 319
 320 OpenProjects IRC Network (irc.openprojects.net) #giFT
 321
 322 (********  SHARING  ********)
 323
 324 read_int: int32
 325 read_str:
 326   int32 len
 327   char[len] string
 328
 329 share_record:
 330   int32 : record_len
 331   int32 : size
 332   string : path/file
 333   int32: path len
 334   string : md5
 335
 336 (* SEARCH *)
 337
 338 int32 : id
 339 int16 : type SEARCH_HIDDEN | SEARCH_MD5 | SEARCH_HOST
 340
 341 type: SEARCH_HIDDEN
 342   query: get_array 4
 343   exclude : ge_array 2
 344   query_str : "*hidden*"
 345   exclude_str : ""
 346 else
 347   query : str
 348   exclude : str
 349 fi
 350
 351 realm : str
 352 size_min : int32
 353 size_max : int32
 354 kbps_min : int32
 355 kbps_max : int32
 356
 357 dec:[
 358 (0)(31)
 359 (0)(200)
 360 (0)(0)(0)(6) id
 361 (0)(1)       type
 362 (106)(111)(104)(110)(110)(121)(0) johnny
 363 (0)          exclude
 364 (0)          realm
 365 (0)(0)(0)(0) size_min
 366 (0)(0)(0)(0) size_max
 367 (0)(0)(0)(0) kbps_min
 368 (0)(0)(0)(0) kbps_max
 369 ]
 370
 371         SEARCH_FILENAME = 0x01,
 372         SEARCH_MD5      = 0x02,
 373         SEARCH_HOST     = 0x04,
 374         SEARCH_LOCAL    = 0x08,
 375         SEARCH_HIDDEN   = 0x10  /* the HIDDEN flag indicates that the human
 376                                  * readable search string will be substituted
 377                                  * by the hashed/tokenized query...this is up to
 378                                  * the implementation how paranoid they wish to
 379                                  * be ;) */
 380                return;
 381
 382 SEARCH REPLY:
 383
 384 int32   id
 385 (* nothing = end of reply *)
 386         /* packet->len == 4 when an EOF came in */
 387
 388                 ip host (=0 local shares)
 389                 int16 port
 390                 int16 http_port
 391                 int32 avail
 392                 int32 size
 393                 string md5
 394                 string filename
 395
 396 (0)(0)(0)(5) search id
 397 (0)(4)      IP
 398 (24)(-96)(124)(71)
 399 (0)(0)(0)(0)(0)(0)(0)(0)(0)(0)(0)(0)
 400 (4)(-65)   port
 401 (4)(-64)   http_port
 402 (0)(0)(0)(5) avail
 403 (0)(0)(121)(35) size
 404 (102)(49)(55)(57)(48)(101)(102)(57)(48)(50)(48)(99)(53)(55)(99)(99)(48)(56)(55)(101)(56)(98)(51)(51)(52)(98)(102)(55)(49)(48)(56)(51)(0) md5(0)
 405 (47)(102)(117)(110)(47)(109)(105)(114)(99)(47)(100)(105)(103)(105)(116)(97)(108)(47)(115)(121)(115)(47)(114)(97)(119)(46)(105)(110)(105)(0) name(0)
 406
 407
 408
 409 TELECHARGEMENT:
 410
 411 G E T   / m e d i a / E n d e r % 2 7 s % 2 0 S a g a % 2 0 5 % 2 0 - % 2 0 E n d e r % 2 7 s % 2 0 S h a d o w . t x t   H T T P / 1 . 1 (13)(10)
 412 R a n g e :   b y t e s = 0 - 8 0 2 5 5 8 (13)(10)
 413 (13)(10)
 414