[PHP] torrent info_hash in db is niet zoekbaar

[Verwijderd]

Hallo,

ik het volgende:
- een torrent tracker in php die er netjes voor zorgt dat torrentjes in eem tabel komen. Als enige aanknooppunt naar de torrent heb ik hier de hash_info
- een stukje code die een torrent file kan uploaden, opslaan op filesystem en een tabel en vervolgens de info_hash ervan kan berekenen.

Een info_hash zal zoiets zijn als :

ºŽë*§Z£ÑÚ	qµežD¼î

Dus ik zou in theorie wat er in mijn tracker-tabel staat moet kunnen koppelen aan wat er in mijn upload-tabel dmv de info_hash.

Als ik een torrent aanmaak (met een willekeurige torrent-client), en deze announce op de tracker, en vervolgens de zelfde torrent upload/opsla en de info_hash bereken/opsla dan gaat er niets mis.
Als ik de 2 hashes uit de tabellen haal ( phpmyadmin ) lijken deze met het blote oog 100% op elkaar.
Ga ik vervolgens zoeken naar de hashes, vanuit tracker-tabel zoeken in upload-tabel en visa-versa, dan wordt in een aantal gevallen een match gevonden (goed!) en in meer gevallen geen match (niet goed!)

De tabellen:
tracker: veld: info_hash - char(20) - latin1_bin
upload: veld: info_hash - char(20) - latin1_bin

Het lijkt er op dat MySQL problemen heeft met de speciale charaters.
Dit omdat phpmyadmin ook meteen aan de gang gaat met converten tijdens een zoek-actie naar een hash:

SELECT *
FROM `peers`
WHERE `info_hash` = CONVERT( _utf8 'ºŽë*§Z£ÑÚ qµežD¼î'
USING latin1 )
COLLATE latin1_bin

en daar dus de spaties uit weg laat, of het herkent als tab ofzo, of andere rare dingen er mee uitspookt...

Op dit moment loop ik dus vast.
Het gaat hier dus niet om de theorie-lessen hoe torrents inelkaar zitten, of hoe legaal of illegaal het allemaal wel niet is wat je met torrens kan gewoon puur waarom ik niet kan zoeken op vreemde teken in een mysql db...

dus.. thanks alvast! Rob

[Megamind]

Ik denk eerder dat je de hash tabel fout uitleest want die zal niet zo opgeslagen worden...

[DaCoTa]

Die hash is geen text, dat is binary. Oftewel, je zou je kolomdefinitie aan moeten passen naar iets als byte[20].

info_hash
The 20 byte sha1 hash of the bencoded form of the info value from the metainfo file. Note that this is a substring of the metainfo file. This value will almost certainly have to be escaped.

[ Voor 54% gewijzigd door DaCoTa op 28-07-2008 18:34 ]

[Niemand_Anders]

Kijk eens naar de PHP bin2hex functie. Overigens wordt een neemt een hexencoded SHA1 hash 40 karakters in beslag (elke byte wordt vertegenwoordigd door 2 karakters (00 tot FF (0 - 255)).

[Cartman!]

Dit lijkt me een encoding probleem, plus dat je het beter als string (hex) kan opslaan dan binair in dit geval zou ik zeggen. Waarom is trouwens je input UTF8 en wil je dit terugconverten naar een latin1 encoding? Laat het lekker UTF8 en gebruik in je hele applicatie UTF8, echt waar, dat voorkomt veel gezeik

[Verwijderd]

nougoed, na wat zoekwerk kwan ik erachter dat de tracker de info_hash als een hex ontvangt, en deze wordt in de database weggeschreven als rare-tekens-string.

na heel veel pogingen om de hashes met elkaar te vergelijken/zoeken heb ik de handdoek in de ring gegooid en een andere manier gemaakt, misschien niet het beste, maar het werkt:

de info_hash die de tracker ontvangt covert ik naar een md5(), ik heb een extra kolom in de tracker toegoevoegd en daar stop ik de md5() in. ( in de query waar de torrents worden ge-announced )
nu bij het uploaden/wegschrijven van de torrent-file zelf heb ik nauurlijk de info_hash, daar bouw ik ook een md5() van.
en de 2 md5() hashes kan ik wel perfect vergelijken/zoeken.

zo werk ik niet dus met die irri info_hash waar je weinig mee kan, maar voor intern gebruik een md5 hash.

Enkel nu ik dit type, hoeveel kans is er dat een md5() van een info_hash op het zelfde uitkomt? weinig lijkt me? ( de tracker is trouwens toch niet echt druk, en dat wordt hij ook niet )

[Verwijderd]

Dan kan je eventueel ook CRC (32 bits) gebruiken, de kans op collisions is minimaal (afhankelijk van je collection) en het is gewoon een int dus matchen is lekker makkelijk. Bij MD5 is de kans op een collision ook minimaal, ik denk zelfs wel volledig uit te sluiten (er zijn algoritmes om collisions te berekenen bij MD5).

Netter zou zijn om gewoon de hash als tekst op te slaan, hiervoor zijn een hoop technieken.
De meest gebruikte techniek is volgens mij base64 encoding volgens RFC 2045 6.8, makkelijk te gebruiken en werkt als een trein.

Je kan ook eenvoudig even de hele handel weer omzetten naar hex, maar dat is iets omslachtiger als de base64 methode en het resultaat is vrijwel gelijk.

[ Voor 12% gewijzigd door Verwijderd op 30-07-2008 03:40 ]

[Verwijderd]

oops, beetje late reactie, nougoed, beter dan nooit.

Naar base64 heb ik ook even gekeken, maar gek genoeg komen daar niet dezelfde resultaten uit... meerdere getest, maar er bleven andere waardes uitkomen.
Na heel veel testen met md5 blijven de resultaten gelijk, dus ik denk dat ik lekker die blijf gebruiken

Ik hoef niet persee het weer om te zetten naar de orginele hash.
trouwens... die kan ik gewoon weer opvragen uit het torrent bestand zou ik hem echt nodig hebben

Dus, opgelost. ik = blij.