Opened 8 years ago

Closed 8 years ago

#5152 closed Bug (duplicate)

The torrent "ids" are reseted each time Transmission is restarted

Reported by: fguillen Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.73
Severity: Normal Keywords: api, rpc
Cc:

Description

I'm working in a web interface for Transmission using the RPC api.

I'm storing extra data for each torrent in an independent database, and I'm connecting my record with the Transmission torrents throw the "id".

But I just realize this identifier is changing every time Transmission is restarted so all my data becomes orphan, or even worst connected to the wrong torrent.

I suggest three options:

  • this number should be permanent and never repited
  • this number should be permanent and reusing the gaps that the removed torrent have left
  • User another identifier like the "hashString"

I consider this a "bug" because the "id" is the primary entry point for the RPC API and it should be reliable.

Thanks for your job!

f.

Attachments (1)

libutp.diff (797 bytes) - added by reardon 8 years ago.
throw signal which resend ack is overun

Download all attachments as: .zip

Change History (6)

comment:1 Changed 8 years ago by reardon

For what it's worth, this issue is now starting to bite me regularly, due to the utp bug (crashing on average 3x/day). I'd like to see an RPC addition to query for ID based on torrent hash, as well as a quick sessionid returned with session info which increments each time transmission-daemon restarts.

comment:2 Changed 8 years ago by cfpp2p

reardon,

do you have anything new about:

the utp bug (crashing on average 3x/day)

other than what you have posted already and if so could you post on #5002

Changed 8 years ago by reardon

throw signal which resend ack is overun

comment:3 Changed 8 years ago by reardon

As I've said elsewhere, the libutp code is, um, dense, and I don't have the time to pull it apart. I made one change which seems to isolate the problem, which is in the resend acknowledgement logic. There is a hard-coded resend ack window, which seems awfully fishy.

Anyone with sufficient hacking skills will see how trivial it is to exploit this. It is seriously dangerous.

The attachment just throws a signal whenever the situation arises. You can "set nr=0" and continue, which just corrupts the ack packets, but so be it.

Wish we could get the libutp folks to maintain...

comment:4 Changed 8 years ago by jordan

cfpp2p, reardon: those last three comments don't have anything to do with this ticket. please keep tickets on-topic.

Last edited 8 years ago by jordan (previous) (diff)

comment:5 Changed 8 years ago by jordan

  • Resolution set to duplicate
  • Status changed from new to closed

This request is a duplicate of bug #3063

Note: See TracTickets for help on using tickets.