ed2k Server !! Sharing-Devils No.3 !! - online *TEST*
Re: ed2k Server !! Sharing-Devils No.3 !! - online *TEST*
what specs do you need for the rust server? how does it compare to others in terms of GPU on memory in your experience?
Re: ed2k Server !! Sharing-Devils No.3 !! - online *TEST*
No GPU is required.
The Rust server really does seem to use fewer resources, which I think is fantastic.
The Rust server really does seem to use fewer resources, which I think is fantastic.
Re: ed2k Server !! Sharing-Devils No.3 !! - online *TEST*
CPU typo. was curious about comparison. OK so less footprint, good
Re: ed2k Server !! Sharing-Devils No.3 !! - online *TEST*
update v18.1 (ed2k-server 0.9.79)
Release 0.9.79: OFFERFILES v1 fast publishing (#19), search ties without hash-range bias (#14)
Nothing changes for an existing configuration: OFFERFILES v1 is off by
default and the content filter is untouched. Details in CHANGELOG.md.
OFFERFILES v1 (#19), the wire contract agreed in the issue
* limits.offerfiles_v1 (default false), offerfiles_batch_max (200),
offerfiles_min_interval_ms (500), offerfiles_global_records_per_sec (5000).
* On: the post-login OP_SERVERIDENT carries offerfiles_v = 1,
offerfiles_batch_max and offerfiles_min_interval_ms (string-named uint32)
with ST_SOFTFILES / ST_HARDFILES, all from one snapshot taken at login and
enforced for the connection's life. All or nothing: soft > 0, batch > 0,
interval > 0, hard > batch, otherwise no tag, an error in the log and
legacy behaviour.
* Per-connection token bucket in records (one batch deep, refills batch_max
per interval): early batches wait, never dropped; pushed frames are still
delivered while waiting. Server-wide ceiling for all v1 connections, FIFO.
A batch above batch_max (below hard) is not indexed, the session stays up.
A session replaced while its batch waited does not index it.
* Off, or for a client that does not read it: byte-identical SERVERIDENT and
unchanged publishing.
* Status tab and /api/stats (offer_v1): policy and counters. README section
"OFFERFILES v1" documents the contract.
* New module src/server/offer_pacing.rs.
Search ties (#14)
* Equal source counts were ordered by FileId, which is shard (by file hash)
then reused slot, so the same hash range won ties on every query. Now a
per-query hash of the file hash, keyed per process; TCP and UDP agree.
* S01E01E02E03 (over six runs) is not sub-tokenised: documented and tested.
Tests: 517 unit + 24 integration pass. The integration cases include the
OFFERFILES v1 contract tests drafted by 3togo for aMule PR #1715 (adapted to
the final keys) and the follow-up cases from that draft. Checked on a running
binary: advertisement, pacing by the bucket and by the ceiling, oversized
batch kept the session, hard boundary closed it, invalid configuration
advertised nothing, option off unchanged.
Release 0.9.79: OFFERFILES v1 fast publishing (#19), search ties without hash-range bias (#14)
Nothing changes for an existing configuration: OFFERFILES v1 is off by
default and the content filter is untouched. Details in CHANGELOG.md.
OFFERFILES v1 (#19), the wire contract agreed in the issue
* limits.offerfiles_v1 (default false), offerfiles_batch_max (200),
offerfiles_min_interval_ms (500), offerfiles_global_records_per_sec (5000).
* On: the post-login OP_SERVERIDENT carries offerfiles_v = 1,
offerfiles_batch_max and offerfiles_min_interval_ms (string-named uint32)
with ST_SOFTFILES / ST_HARDFILES, all from one snapshot taken at login and
enforced for the connection's life. All or nothing: soft > 0, batch > 0,
interval > 0, hard > batch, otherwise no tag, an error in the log and
legacy behaviour.
* Per-connection token bucket in records (one batch deep, refills batch_max
per interval): early batches wait, never dropped; pushed frames are still
delivered while waiting. Server-wide ceiling for all v1 connections, FIFO.
A batch above batch_max (below hard) is not indexed, the session stays up.
A session replaced while its batch waited does not index it.
* Off, or for a client that does not read it: byte-identical SERVERIDENT and
unchanged publishing.
* Status tab and /api/stats (offer_v1): policy and counters. README section
"OFFERFILES v1" documents the contract.
* New module src/server/offer_pacing.rs.
Search ties (#14)
* Equal source counts were ordered by FileId, which is shard (by file hash)
then reused slot, so the same hash range won ties on every query. Now a
per-query hash of the file hash, keyed per process; TCP and UDP agree.
* S01E01E02E03 (over six runs) is not sub-tokenised: documented and tested.
Tests: 517 unit + 24 integration pass. The integration cases include the
OFFERFILES v1 contract tests drafted by 3togo for aMule PR #1715 (adapted to
the final keys) and the follow-up cases from that draft. Checked on a running
binary: advertisement, pacing by the bucket and by the ceiling, oversized
batch kept the session, hard boundary closed it, invalid configuration
advertised nothing, option off unchanged.


