hash generatie

[Verwijderd]

Ik wil in C++ een unieke id genereren door een hash te genereren uit een integer (systeemtijd) en een string (namelijk de naam van de gebruiker).

Nu heb ik op internet lopen zoeken naar wat hash theorie, maar ik kan geen site vinden waar dit duidelijk wordt uitgelegd. Heeft iemand misschien een link voor mij of een voorbeeld?

[Verwijderd]

heb je hier misschien iets aan..?

//edit: eerste hit bij google als je zoekt op 'c++ md5'

[ Voor 27% gewijzigd door Verwijderd op 17-01-2005 19:08 ]

[Daos]

Je hebt geen theorie nodig, maar een algoritme (bv MD5).

[Verwijderd]

Daos schreef op maandag 17 januari 2005 @ 19:08:
Je hebt geen theorie nodig, maar een algoritme (bv MD5).

zoals die link dus :-) Ik zat te zoeken op een md5functie in c..

[The Lord]

Als je een unieke ID wilt creëren, waarom dan niet een incrementele ID? Als je perse iets anders wilt is een GUID waarschijnlijk een beter idee dan zelf proberen een algoritme te vinden.

En van MD5 weet je zeker dat het niet zeker is dat de string uniek is; twee strings kunnen nu eenmaal dezelfde hash hebben.

Misschien kun je beter aangeven wat je wil bereiken met de unieke ID?

edit:
Nu ik het nog een keer lees denk ik te begrijpen wat je wil, namelijk een logon versleutelen?

[ Voor 13% gewijzigd door The Lord op 17-01-2005 19:17 ]

[Verwijderd]

The Lord schreef op maandag 17 januari 2005 @ 19:15:
Als je een unieke ID wilt creëren, waarom dan niet een incrementele ID? Als je perse iets anders wilt is een GUID waarschijnlijk een beter idee dan zelf proberen een algoritme te vinden.

En van MD5 weet je zeker dat het niet zeker is dat de string uniek is; twee strings kunnen nu eenmaal dezelfde hash hebben.

Misschien kun je beter aangeven wat je wil bereiken met de unieke ID?

edit:
Nu ik het nog een keer lees denk ik te begrijpen wat je wil, namelijk een logon versleutelen?

Het moet een multi-platform applicatie worden in een netwerkomgeving.
Het betreft een spel waarbij een player zich kan aanmelden. Als de player zijn naam invult dan wil ik vervolgens aan de hand hiervan en de systeemtijd een unieke hash genereren.

[Sendy]

Waarom moet-ie uniek zijn? Als-ie uniek moet zijn, dan kan je geen hash gebruiken. Een hash is per definitie niet uniek (want dat is ook zijn kracht!).

edit:

Alarmnummer >
De eerste paragraaf van het artikel over hashfuncties op Wikipedia ondersteunt ons beider zienswijze (ik ben niet zeker van de naamvallen). Het is een nuance verschil.

[ Voor 77% gewijzigd door Sendy op 17-01-2005 23:37 ]

[Alarmnummer]

Sendy schreef op maandag 17 januari 2005 @ 19:28:
Waarom moet-ie uniek zijn? Als-ie uniek moet zijn, dan kan je geen hash gebruiken. Een hash is per definitie niet uniek (want dat is ook zijn kracht!).

Per definitie niet uniek wil ik niet zeggen. In het ruimste geval zal een unieke key een goeie hashcode zijn, en in het 'smalste' geval een constante. Ik ben het dus niet met je eens,

[Remus]

Is het niet makkelijker om je server-applicatie gewoon een incremental id aan te laten maken? Of zit er een bepaald beveiligingsid achter (id kan niet gespoofd worden?)

[Verwijderd]

Sendy schreef op maandag 17 januari 2005 @ 19:28:
Waarom moet-ie uniek zijn? Als-ie uniek moet zijn, dan kan je geen hash gebruiken. Een hash is per definitie niet uniek (want dat is ook zijn kracht!).

een aantal spelelementen zijn gekoppeld en dus afhankelijk van de id. Vandaar dat deze uniek moet zijn.

Het is inderdaad zo dat niet 100% gegarandeerd kan worden dat de hash uniek is, maar de kans is denk ik heel klein dat je twee dezelfde waarden krijgt als je met een goed algoritme hasht op zowel de tijd als de speler naam

Dit lijkt mij een goede oplossing, maar als er een beter alternatief is dan hoor ik dat natuurlijk graag

[Verwijderd]

Remus schreef op maandag 17 januari 2005 @ 19:32:
Is het niet makkelijker om je server-applicatie gewoon een incremental id aan te laten maken? Of zit er een bepaald beveiligingsid achter (id kan niet gespoofd worden?)

Een incremental id zou een goede oplossing zijn. Probleem is echter dat er meerdere processen zijn, waaronder een playerprocess. Het punt is dat de player zijn eigen id MOET genereren en dat de andere processen hier vervolgens gebruik van maken

[Creepy]

Verwijderd schreef op maandag 17 januari 2005 @ 19:37:
[...]


Een incremental id zou een goede oplossing zijn. Probleem is echter dat er meerdere processen zijn, waaronder een playerprocess. Het punt is dat de player zijn eigen id MOET genereren en dat de andere processen hier vervolgens gebruik van maken

En je probleem met een incremental hierbij is dat???

[Verwijderd]

Creepy schreef op maandag 17 januari 2005 @ 19:41:
[...]

En je probleem met een incremental hierbij is dat???

Er kunnen bijvoorbeeld meerdere machines zijn waar meerdere playerprocessen kunnen worden opgestart.

Een playerprocess representeert precies één speler, en moet dus zijn eigen unieke id genereren.

Er is natuurlijk een game process waar de spelers zich 'aanmelden' , je zou zeggen laat het game process de id's genereren, maar aangezien het een gedistribueerde applicatie betreft moet elke speler zijn data eerst in de gedistribueerde database schrijven, waarbij er dus een (unieke) primary key gegenereerd moet worden

[The Lord]

Klinkt alsof een GUID hier goed bruikbaar is. Heb alleen geen flauw idee wat voor algoritme daarvoor gebruikt wordt.

[ThunderNet]

Met een functie kun je Windows vragen een GUID voor je te genereren.

[Soultaker]

De simpelste en beste oplossing lijkt mij om de client een id te laten vragen bij de server. De client zegt: "Hallo, ik ben Harry en mijn systeemtijd is 21:44:34.271." De server slaat dit op en retourneert een random unieke (misschien gewoon oplopende, maar dat is misschien fraudegevoelig) identifier.

Dan weet de server altijd wie er bij een bepaalde identifier hoort en de client weet gewoon welke identifier bij hemzelf hoort.

[T-MOB]

Is het niet nog makkelijker om gewoon niet te hashen. Gewoon een naam en unixtimstamp aan elkaar plakken. De kans dat die info uniek is is groter dan de kans dat een hash van die info uniek is.

[Exe-cuter]

offtopic:
Toen ik de topictitel zag op tweakers.net dacht ik dat dit een huiskamer-topic moest voorstellen : "De generatie die opgroeide met hash"

[the_stickie]

Exe-cuter schreef op maandag 17 januari 2005 @ 21:58:

offtopic:
Toen ik de topictitel zag op tweakers.net dacht ik dat dit een huiskamer-topic moest voorstellen : "De generatie die opgroeide met hash"

offtopic:
op de frontpage komen nooit Huiskamer topics te staan

[curry684]

Verwijderd schreef op maandag 17 januari 2005 @ 19:37:
[...]

Een incremental id zou een goede oplossing zijn. Probleem is echter dat er meerdere processen zijn, waaronder een playerprocess. Het punt is dat de player zijn eigen id MOET genereren en dat de andere processen hier vervolgens gebruik van maken

Dit is onzin, en enorm slecht. Player- en sessionbeheer moet per definitie in het serverproces plaats vinden, anders zet je de deur wagenwijd open naar cheaters en hackers.

[Verwijderd]

De client hoeft helemaal niet zijn eigen ID te genereren; hij kan het ook uitgedeeld krijgen van een server (de game server, of een centrale metaserver met een user database erop).

Door de manier waarop je van plan was je UID te berekenen schijnt het mij toe dat een tijdelijk ID voldoende is; dwz., de eis is dat er geen conflict mag optreden binnen één gamesessie. Ik neem dus aan dat het niet nodig is dat
• de UID nooit meer gebruikt mag worden in een ander spel in de toekomst
• de UID altijd dezelfde speler aan moet wijzen

Een van deze twee eisen erbij (allebei kan niet), zou van je UID een GUID maken (de eerste een GUID van een sessie, de tweede een GUID van een speler).

Maar als deze eisen inderdaad niet nodig zijn... bwoh... of je husselt een beetje met de systeemtijd met een willekeurig gegenereerde prefix ervoor (of wat dan ook, genereer iets wat een kleine kans heeft om gedupliceerd te worden, harde garanties zijn niet nodig), of laat de server IDs uitdelen.

De laatste oplossing heeft trouwens verreweg de voorkeur, als je het mij vraagt.

[ Voor 6% gewijzigd door Verwijderd op 18-01-2005 01:33 ]

[Woy]

Tuurlijk moet je de server id's laten genereren. De client's heb je zelf niet in beheer dus mag je data die van de client afkomstig is eigenlijk nooit vertrouwen. Er kan altijd iemand zijn die een kleine aanpassing in je client maakt waardoor de ID generatie helemaal in de soep loopt.

De Server zou dus gewoon de id's uit moeten delen.

[Stealth2000]

In daywalker z'n geval kan je niet expliciet spreken van een client en server. Je kan het meer vergelijken met p2p. En aangezien het spel meerdere malen opgestart wordt zou een incremental ID leiden tot gelijke id's aangezien elke client bij 1 begint.

Overigens betreft het een demo voor commerciele software en geen echte game... cheaters zijn er niet

@Daywalker;
Kijk hier ff naar;
http://www.partow.net/programming/hashfunctions/index.html

edit; Overigens zou je ook een beetje kunnen sjoemelen door bijv. combinatie van srand() te gebruiken oid. Als je denkt niet 1000en clients op te starten that is.

[ Voor 17% gewijzigd door Stealth2000 op 18-01-2005 18:34 ]

[curry684]

Ook in P2P heb je altijd een 'server' en een 'client', dat wordt middels negotiation afgesproken. Punt is dat *iemand* de TCP-verbinding moet initieren, en de andere moet 'm accepteren. Daarom heb je ook SuperNodes in Gnutella e.d.

[Soultaker]

offtopic:
De supernodes in Gnutella zijn geen supernodes alleen omdat ze connecties accepteren (dat doen bijna alle clients, want clients kunnen ook onderling verbinden) maar alleen omdat de supernodes een index bijhouden van de bestanden in het netwerk.

Verder heb je in een peer-to-peer netwerk dat op UDP-gebaseerd is, zoals de implementatie van een kademlia-netwerk in eMule, echt geen onderscheid tussen client en server; er zijn alleen nodes, die onderling berichten uitwisselen.