mboost-dp1
SKAT
#52: Afhænger vel helt af hvordan man bruger det sessionID - det er jo ikke nødvendigvis et ID der skal helt ud til klienten.
I dette tilfælde er det næppe webserverne der tilgår databasen med skatteoplysningerne direkte - de tilgåes formentlig igennem et internt system hvor dette sessionID er relevant. Imellem klienten og webserverne har man jo allerede en sessionID håndtering i ASP.NET (som SKAT benytter) og derfor er det næppe her det er relevant.
Derudover tror jeg at de har tænkt over den problemstilling, for der er samme problematik med de timestamps de benytter nu (mulighed for spoofing) og selvom vi godt kan blive enige om at det ikke er verdens smarteste løsning de har valgt, så er der dog formentlig grænser for hvor dumme de har været :-)
I dette tilfælde er det næppe webserverne der tilgår databasen med skatteoplysningerne direkte - de tilgåes formentlig igennem et internt system hvor dette sessionID er relevant. Imellem klienten og webserverne har man jo allerede en sessionID håndtering i ASP.NET (som SKAT benytter) og derfor er det næppe her det er relevant.
Derudover tror jeg at de har tænkt over den problemstilling, for der er samme problematik med de timestamps de benytter nu (mulighed for spoofing) og selvom vi godt kan blive enige om at det ikke er verdens smarteste løsning de har valgt, så er der dog formentlig grænser for hvor dumme de har været :-)
Alt er vel en cost/benefit betragtning værd. Ved vi noget om hvor og hvornår kilden til fejlen opstod?
Der bliver snakket meget om session ids men kunne problemet ikke også tænkes at være opstået på en central mainframe i gamle programmer? Ingen kæde er jo stærkere end det svageste led.
Nu er DB2's timestamp eksempelvis nøjagtigt ned til en milliontedel sekund og der forekommer det da også at flere transaktioner får samme timestamps når man eksempelvis kører flere parallelle batch kørsler.
Løsningen med timestamps vil nok være tilstrækkelig i langt de fleste situationer. Begynder man først at tage numre fra et interval og markerer de enkelte som brugte introducerer man flaskehals og deadlock/timeout situationer da flere processer risikerer at holde de centrale ressourcer. Dertil kommer commit
Selvfølgelig kan man sige at fejl ikke burde ske, men det ER muligt at gå over åen efter vand selvom det ikke altid er tilrådeligt.
Jeg tror at SKAT har mange andre og bedre steder at bruge skatteydernes penge i deres IT systemer end aktivt at sikre mod alle tænkelige og usandsynlige fejl upfront.
Der bliver snakket meget om session ids men kunne problemet ikke også tænkes at være opstået på en central mainframe i gamle programmer? Ingen kæde er jo stærkere end det svageste led.
Nu er DB2's timestamp eksempelvis nøjagtigt ned til en milliontedel sekund og der forekommer det da også at flere transaktioner får samme timestamps når man eksempelvis kører flere parallelle batch kørsler.
Løsningen med timestamps vil nok være tilstrækkelig i langt de fleste situationer. Begynder man først at tage numre fra et interval og markerer de enkelte som brugte introducerer man flaskehals og deadlock/timeout situationer da flere processer risikerer at holde de centrale ressourcer. Dertil kommer commit
Selvfølgelig kan man sige at fejl ikke burde ske, men det ER muligt at gå over åen efter vand selvom det ikke altid er tilrådeligt.
Jeg tror at SKAT har mange andre og bedre steder at bruge skatteydernes penge i deres IT systemer end aktivt at sikre mod alle tænkelige og usandsynlige fejl upfront.
starfish (55) skrev:Alt er vel en cost/benefit betragtning værd.
starfish (55) skrev:Jeg tror at SKAT har mange andre og bedre steder at bruge skatteydernes penge i deres IT systemer end aktivt at sikre mod alle tænkelige og usandsynlige fejl upfront.
Det er selvindlysende at man ikke kan bruge ubegrænsede resourcer på at sikre et sådant system.
Men borgerne har en rimelig forventning om at skattevæsenet ikke udleverer oplysninger om deres private økonomiske forhold til andre.
Borgernes tryghed er mange penge værd.
#55 Omkostningerne ved synkroniseret incrementering af en ID er altså ud i det teoretiske, det vil reelt først blive et problem på samme tidspunkt som din 100ns opløste timer begynder at spytte ens værdier ud meget meget ofte.
Det tager jo altså ikke 100ns at incrementere en værdi, så hyppigheden af to cpu'er der ønsker at incrementere værdien samtidig vil være lige så lav om ikke lavere end hyppigheden af sammenfald i timeren.
Det tager jo altså ikke 100ns at incrementere en værdi, så hyppigheden af to cpu'er der ønsker at incrementere værdien samtidig vil være lige så lav om ikke lavere end hyppigheden af sammenfald i timeren.
#57
Nu beskæftiger jeg mig ikke super meget med sådanne synkroniserede id'er og professionelt har jeg kun arbejdet på mainframes, så det er muligt jeg overser noget.
Jeg kender umiddelbart 3 løsninger fra de arbejdsgivere jeg har haft.
1) Timestamp leveret af den underliggende database. Ikke særligt unikt som det jo fremgår, men super hurtigt og godt i rigtigt mange tilfælde. Det giver muligheden for at generere id'er direkte i SQL uden at skulle have alverdens modul ind over.
2) "Alfanumerisering" af maskinens store clock. Mig bekendt er den en atomar operation, så den kan ikke forekomme flere gange på samme maskine forudsat at man lukker maskinen ved sommer/vintertidsskift. Noget mere sikker end timestampløsningen, men der er en smule mere overhead ved at alle koncernens systemer skal gennem samme modul for at få detteid.
3) En tabel med en counter i, som man så tilgår via et centralt modul. Dette er vel den sikreste metode men det skaber vel en del problemer med at den record counteren ligger i bliver en flaskehals? En masse forskellige processer som tilgår den samme record med vidt forskellige commit frekvenser vil vel give ventetider som ikke er ønskeværdige. Jeg ved ihvertfald sammenfald imellem pages på databasen parallelle processer imellem giver en del dårligere performence og nedkørsler pga. timeouts i databasen.
Så set fra en udviklers synspunkt (mit) kan jeg bedst lide løsning 1, evt. krydret med en tabelstruktur som ikke tillader dubletter på primary key og håndtering af evt. dublicate row ved oprettelse. Det giver efter min mening den mest overskuelige kode. Husk på at på mainframes med proedurelle sprog (COBOL, NATURAL, etc.) er der en del kode overhead for at kalde andre moduler. Det er ikke bare at dotte sig frem ligesom i et javamiljæ med et giv.mig.unikt.et.id(nøgle) operationskald :)
Der er jo også hele delen med vedligeholdelsen af koden bagefter.
Kan du evt. kaste lys over hvilke løsningsmodeller du bruger?
Man kan jo altid lære lidt nyt jo :-)
Nu beskæftiger jeg mig ikke super meget med sådanne synkroniserede id'er og professionelt har jeg kun arbejdet på mainframes, så det er muligt jeg overser noget.
Jeg kender umiddelbart 3 løsninger fra de arbejdsgivere jeg har haft.
1) Timestamp leveret af den underliggende database. Ikke særligt unikt som det jo fremgår, men super hurtigt og godt i rigtigt mange tilfælde. Det giver muligheden for at generere id'er direkte i SQL uden at skulle have alverdens modul ind over.
2) "Alfanumerisering" af maskinens store clock. Mig bekendt er den en atomar operation, så den kan ikke forekomme flere gange på samme maskine forudsat at man lukker maskinen ved sommer/vintertidsskift. Noget mere sikker end timestampløsningen, men der er en smule mere overhead ved at alle koncernens systemer skal gennem samme modul for at få detteid.
3) En tabel med en counter i, som man så tilgår via et centralt modul. Dette er vel den sikreste metode men det skaber vel en del problemer med at den record counteren ligger i bliver en flaskehals? En masse forskellige processer som tilgår den samme record med vidt forskellige commit frekvenser vil vel give ventetider som ikke er ønskeværdige. Jeg ved ihvertfald sammenfald imellem pages på databasen parallelle processer imellem giver en del dårligere performence og nedkørsler pga. timeouts i databasen.
Så set fra en udviklers synspunkt (mit) kan jeg bedst lide løsning 1, evt. krydret med en tabelstruktur som ikke tillader dubletter på primary key og håndtering af evt. dublicate row ved oprettelse. Det giver efter min mening den mest overskuelige kode. Husk på at på mainframes med proedurelle sprog (COBOL, NATURAL, etc.) er der en del kode overhead for at kalde andre moduler. Det er ikke bare at dotte sig frem ligesom i et javamiljæ med et giv.mig.unikt.et.id(nøgle) operationskald :)
Der er jo også hele delen med vedligeholdelsen af koden bagefter.
Kan du evt. kaste lys over hvilke løsningsmodeller du bruger?
Man kan jo altid lære lidt nyt jo :-)
mstify (53) skrev:ASP.NET (som SKAT benytter)
www.skat.dk er ASP.NET baseret men www.tastselv.skat.dk er så vidt jeg kan se WebSphere AS med Struts (IBM HTTP Server i response header og URL's som slutter med .do ligner ihvertfald sådan noget).
briancaos (30) skrev:Det er altså temmeligt usandsynligt at 2 brugere får samme nøgle, hvis nøglen generes med mikrosekunder som præcision: 2009-06-11:12:00:00:123456 er ganske præcist.
"temmeligt usandsynligt" er software engineering når det er værst.
Hvis vi forestiller os at 100000 logger på og requester sådan en timestamp fordelt tilfældigt over en time, så er der lige knap 50% sandsynlighed for at der vi være mindst et tilfælde hvor to requester timestamp indenfor samme mikrosekund.
En variant af birthday pardokset.
Og jeg må tilstå at jeg ikke har beregnet sandsynligheden men kun målt den ved simulation.
#timestamp
Og førend nogen går i gang me dat bruge timestamp må vil helle lige nævne den vigtige lille detalje:
- en funktion der returnerer tid bruger en vis unit X i resultatet
- en funktion der returnerer tid springer med Y
Det er givet at Y>=X, men det er ikke givet at Y=X. Det er faktisk sjældent at Y=X.
Så selvom man har en funktion som f.eks. returnerer tiden i mikrosekunder, så betyder det at X er 1 mikrosekund, men man skal læse det med småt eller evt. selv teste for at finde Y. Det kan sagtens tænkes at Y er 10 mikrosekunder og værdierne sprinter 10, 20, 30, ... etc.. Og dermed at funktionen kun returnerer 100000 unikke værdier indenfor et sekund og ikke de forventede 1 million.
Jeg har ingen grund til at tro, at det har været tilfældet her. Men det er noget som folk der bruger meget præcise timestamp skal være opmærksom på.
Og førend nogen går i gang me dat bruge timestamp må vil helle lige nævne den vigtige lille detalje:
- en funktion der returnerer tid bruger en vis unit X i resultatet
- en funktion der returnerer tid springer med Y
Det er givet at Y>=X, men det er ikke givet at Y=X. Det er faktisk sjældent at Y=X.
Så selvom man har en funktion som f.eks. returnerer tiden i mikrosekunder, så betyder det at X er 1 mikrosekund, men man skal læse det med småt eller evt. selv teste for at finde Y. Det kan sagtens tænkes at Y er 10 mikrosekunder og værdierne sprinter 10, 20, 30, ... etc.. Og dermed at funktionen kun returnerer 100000 unikke værdier indenfor et sekund og ikke de forventede 1 million.
Jeg har ingen grund til at tro, at det har været tilfældet her. Men det er noget som folk der bruger meget præcise timestamp skal være opmærksom på.
Cyrack (8) skrev:Hvordan vil du garantere at en stump data er unik? Med mindre man bruger et stykke dedikeret hardware, der kun kan benyttes af én tråd af gangen, så er det meget svært. Og hvis man laver ressourcen så der kun er én der kan læse af gangen, så går det (med al sandsynlighed) ud over performance.
Alle databaser har løst problemet.
Det koster naturligvis lidt. Men det burde sagtens kunne bruge si denne sammenhæng.
Du har glemt en detalje. Hvordan ved en server, hvor den skal starte efter en genstart? Det kan selvfølgelig løses, men man skal tænke sig om hvis man både vil garantere at det stadig virker efter en server er crashet og udskiftet, og også vil garantere, at det er effektivt.mstify (45) skrev:#44: Hvis du har en 64-bit integer og du bruger de første 2 bytes til at betegne server-serien (hermed kan vi dele systemet ud over 65536 servere), så har vi stadig 2^48 id'er tilbage til hver enkelt server - hvilket er 281.474.976.710.656 sessions pr. server.
Lad os sige at den enkelte server opretter 10.000 sessions i sekundet i gennemsnit, så løber vi tør om:
2 ^ 48 / 10.000 / 60 / 60 / 24 / 365 = 892 år :-)
Jeg tror dit problem er ret hypotetisk :)
Min pointer er, at det er ikke så nemt som folk antager.
Nogen gange er en simulation godt nok. Jeg prøvede dog at gennemføre udregningerne og nu undrer jeg mig over, at du kun fik 50%.arne_v (61) skrev:"temmeligt usandsynligt" er software engineering når det er værst.
Hvis vi forestiller os at 100000 logger på og requester sådan en timestamp fordelt tilfældigt over en time, så er der lige knap 50% sandsynlighed for at der vi være mindst et tilfælde hvor to requester timestamp indenfor samme mikrosekund.
En variant af birthday pardokset.
Og jeg må tilstå at jeg ikke har beregnet sandsynligheden men kun målt den ved simulation.
Der er 60*60*10^6 mikrosekunder på en time.
Med 100000 logins er der 50000*99999 par der hver kan kolidere med sandsynlighed på 1/(60*60*10^6)
Det gennemsnitlige antal kollisioner på en time bliver dermed (50000*99999)/(60*60*10^6)=1.388875
Mr.Weasel (11) skrev:Er det ikke derfor man normalt bruger UUIDer til den slags?
mrF0x (38) skrev:Jo det er det da ;) UUID/GUID...
Holger_dk (51) skrev:tja... ville da også have brugt en GUID/UUID...
Der er forskellige implementationer af GUID/UUID, men de fleste af dem kan godt returnere duplikater. Det er bare ret usandsynligt.
Man ville formentlig godt kunne leve med den risiko, da den ikke er meget større end risikoen for at gætte session id af en anden bruger.
Men givet at der eksisterer metoder som garanterer unikhed, så er det stadig ikke en attraktiv løsning.
kasperd (64) skrev:Nogen gange er en simulation godt nok. Jeg prøvede dog at gennemføre udregningerne og nu undrer jeg mig over, at du kun fik 50%.
Der er 60*60*10^6 mikrosekunder på en time.
Med 100000 logins er der 50000*99999 par der hver kan kolidere med sandsynlighed på 1/(60*60*10^6)
Det gennemsnitlige antal kollisioner på en time bliver dermed (50000*99999)/(60*60*10^6)=1.388875
E(x) og P(x>0) er jo ikke umiddelbart nemme at sammenligne.
Men jeg checkede lige beregningerne en ekstra gang og der var faktisk et long problem - den rigtige sandsynlighed er ca. 75%.
starfish (58) skrev:3) En tabel med en counter i, som man så tilgår via et centralt modul. Dette er vel den sikreste metode men det skaber vel en del problemer med at den record counteren ligger i bliver en flaskehals? En masse forskellige processer som tilgår den samme record med vidt forskellige commit frekvenser vil vel give ventetider som ikke er ønskeværdige. Jeg ved ihvertfald sammenfald imellem pages på databasen parallelle processer imellem giver en del dårligere performence og nedkørsler pga. timeouts i databasen.
Lang de fleste databaser understøtter enten auto increment eller sequence generering.
Hvilket er det samme som dit forslag bare "indbygget" i databasen.
Det fungerer normalt ganske udmærket.
Selv med en tabel som man selv styrer bør det være OK i forhold til den volumen vi diskuterer her.
I timestamp collision eksemplet regnede jeg med 100000 requests på en time. Det er kun 1667 TPM. Det vil ikke bringe databasen i knæ.
Regus (49) skrev:Du indeler bare en 64 bit int i nogle segmenter, et segment pr server og så lægger de bare én til i en synkroniseret metode hver gang de skal bruge en ny ID og viola unikke ID'er.
Der er to problemer med denne ide.
1) Der vil opstå duplikater ved genstart af server. Hvis der loadbalances og session replikeres vil der sågar kunne være to samtidige brugere som har fået samme id gemt i sessionen.
2) Det kræver at servere skal konfigureres unikt. Det er notorisk et problem - før eller senere går det galt og to servere får samme konfiguration.
Windcape (7) skrev:Jeg tror mere at problemet er, at webserveren som giver ud disse tidskoder til at identificere den enkelte session
ulrikl (9) skrev:#7 tvivler nu på at webserveren bruger denne metode til at identificere sine sessioner, så tror jeg problemet ville være kommet frem i lyset i før, om muligheden for at brugere overtager hinandens sessioner hvis man logger ind på samme tid. Og desuden ville det være mega nemt at hijacke andres sessioner.
buchi (23) skrev:OK, kan hører der er mange der taler om SISSION IDs. I skal se. Det er nok dem de har skulle generer. problemet er jo at der er to brugere der har fået det samme session id, og derfor, sjovt nok, har haft adgang til hinandens session!!
mstify (53) skrev:#52: Afhænger vel helt af hvordan man bruger det sessionID - det er jo ikke nødvendigvis et ID der skal helt ud til klienten.
I dette tilfælde er det næppe webserverne der tilgår databasen med skatteoplysningerne direkte - de tilgåes formentlig igennem et internt system hvor dette sessionID er relevant. Imellem klienten og webserverne har man jo allerede en sessionID håndtering i ASP.NET (som SKAT benytter) og derfor er det næppe her det er relevant.
starfish (55) skrev:Der bliver snakket meget om session ids men kunne problemet ikke også tænkes at være opstået på en central mainframe i gamle programmer? Ingen kæde er jo stærkere end det svageste led.
Vi ved ikke hvad det der id som burde være unikt er blevet brugt til.
Men jeg tror ikke meget på session id.
* WebSphere genererer også dette automatisk og det kan ikke kontrolleres af applikationen (ihvertfald ikke med standard baseret kode).
* Problemet er beskrevet som at give adgang til andres skatte mappe ikke at sessionerne generelt blev filtret ind i hinanden.
Jeg får associationer i retning af navnet på et temp dir med temp filer i.
fennec (31) skrev:Øøøø. Har Skat ikke allerede et unikt ID?? Det hedder CPR nr...
Brugerne skal jo logge ind, og under login proceduren ved de 100% hvem man er og hvad dennes CPR nr er.
En kryptering af SessionID + cpr = 100% unik ID.
(Eller har jeg overset noget??)
Både session id or CPR skulle være unikke.
Men nogen gange er det ikke så nemt.
Business logic layer koden skal være uafhængig af web frontend og kan derfor ikke hente session id. CPR nummer er i en database som kun bruges ved login mens den relevante kode bruger en anden database.
Så skal der enten rearchitectes eller man skal finde på et workaround.
Ofte burde man rearchitecte men med en truende deadline prioriteres de hurtige løsninger ofte.
#unikke id's
Der er efter min mening 3 acceptable måder at gribe det an på:
1) Bruge GUID/UUID og acceptere den lille chance for kollisioner.
2) Bruge databasens auto increment eller sequence generator funktionalitet og acceptere at det bruger lidt database resourcer.
3) Bruge Scott Amblers High Low strategy.
Re 3)
Den minder faktisk lidt om Regus's model, men den kræver ikke server specifik konfiguration og giver ikke problemer ved genstart af server.
Ideen er at lade id bestå af en high part og en low part.
High part hentes fra database (auto increment i dummy tabel, sequence generator eller en custom tabel kan bruges).
Low part er en simpel counter i memory.
High part læses ved server start og når low part ikke kan øges mere.
Alle servere er ens fordi de henter high part på samme vis - de får bare en forskellig værdi.
Eneste ulempe ved en server genstart er at et antal low værdier aldrig bliver brugt. De genererede værdier er stadig unikke.
Performance er glimrende fordi der er meget få database operationer og rigtigt mange optællinger i memory.
Der er efter min mening 3 acceptable måder at gribe det an på:
1) Bruge GUID/UUID og acceptere den lille chance for kollisioner.
2) Bruge databasens auto increment eller sequence generator funktionalitet og acceptere at det bruger lidt database resourcer.
3) Bruge Scott Amblers High Low strategy.
Re 3)
Den minder faktisk lidt om Regus's model, men den kræver ikke server specifik konfiguration og giver ikke problemer ved genstart af server.
Ideen er at lade id bestå af en high part og en low part.
High part hentes fra database (auto increment i dummy tabel, sequence generator eller en custom tabel kan bruges).
Low part er en simpel counter i memory.
High part læses ved server start og når low part ikke kan øges mere.
Alle servere er ens fordi de henter high part på samme vis - de får bare en forskellig værdi.
Eneste ulempe ved en server genstart er at et antal low værdier aldrig bliver brugt. De genererede værdier er stadig unikke.
Performance er glimrende fordi der er meget få database operationer og rigtigt mange optællinger i memory.
#0 << Der bør til enhver tid benyttes (evt. timestamp +) længere, vilkårligt genereret ID (fx UUID, som flere nævner). De fleste (alle?) databaseimplementationer tilbyder i øvrigt unik ID-generering.
I øvrigt må "mikrosekund" være en fejl, idet uret kun leverer milisekundopløsning.
#18 << Sådan en fejl må altså aldrig opstå - og selv hvis der er så uskolede udviklere på holdet, bør fejlen fanges under QA! (Og hvis der ikke er grundig QA på et projekt af den vigtighed...)
#26 << Udover min kommentar til #0: Du kan i ingen DBimplementation opdatere eller tilføje mere end én række ad gangen.
#27 << Hvad skulle han ellers spørge efter? Den nye kode tilsendes jo personens CPR-adresse, så den del af sikkerhedskæden er langt fra svageste led.
#36 << DBserverne (eneste argument for at have flere i så simpelt et system er i øvrigt redundans) er synkrone, så det er ikke et issue.
##61+64 << Husk intuitionen; virker det sandsynligt, at der med 100k logins fordelt vilkårligt udover 3,6G µs vil være så stor chance for, at to logger ind på samme µs?
Det er en klassisk terningkastproblematik - omend med en meget "stor" terning; kast en 3,6G-sidet terning 100k gange. Hvad er sandsynligheden for, at alle kast giver et unikt resultat?
Det første kast er unikt - med en sandsynlighed på 3,6G/3,6G, og så der er 99999 kast tilbage.
Kast 2 er med (3,6G-1)/3,6G sandsynlighed unikt.
Kast 3 er med (3,6G-2)/3,6G sandsynlighed unikt.
.
.
.
Kast 100000 er med (3,6G-99999)/3,6G sandsynlighed unikt.
Alle disse sandsynligheder "ganges sammen", hvilket giver 24,94% sandsynlighed for, at alle "kast" er unikke - og således, at der ved 100k logins over en time med 3,6G unikke timestamps med små 25% sandsynlighed ikke vil være sammenfald.
Det er et spørgsmål om kombinatorik - lidt som arne_v nævner vedr. fødselsdags"paradokset", og regnestykket skrives således:
s = 3,6G
n = 100k
s!/(n-1)!/s^n - eller som produktet af (s-x)/s, med værdier af x fra 0 til n-1.
#64 << Det er ikke relevant, hvor serveren starter efter genstart, da alle sessioner alligevel tabes ved genstart. I øvrigt kan serveren let holde styr på, hvortil den er nået.
Du kan da ikke kombinere ved at gange n/2 med n-1 - ikke mindst kolliderer værdierne ikke kun parvis.
#65 << UUID kolliderer "ikke" - og i øvrigt sætter man altid unik-flag på rækken med UUIDs og errorhandling ved konflikt, så problemet kan højest blive teoretisk.
I øvrigt må "mikrosekund" være en fejl, idet uret kun leverer milisekundopløsning.
#18 << Sådan en fejl må altså aldrig opstå - og selv hvis der er så uskolede udviklere på holdet, bør fejlen fanges under QA! (Og hvis der ikke er grundig QA på et projekt af den vigtighed...)
#26 << Udover min kommentar til #0: Du kan i ingen DBimplementation opdatere eller tilføje mere end én række ad gangen.
#27 << Hvad skulle han ellers spørge efter? Den nye kode tilsendes jo personens CPR-adresse, så den del af sikkerhedskæden er langt fra svageste led.
#36 << DBserverne (eneste argument for at have flere i så simpelt et system er i øvrigt redundans) er synkrone, så det er ikke et issue.
##61+64 << Husk intuitionen; virker det sandsynligt, at der med 100k logins fordelt vilkårligt udover 3,6G µs vil være så stor chance for, at to logger ind på samme µs?
Det er en klassisk terningkastproblematik - omend med en meget "stor" terning; kast en 3,6G-sidet terning 100k gange. Hvad er sandsynligheden for, at alle kast giver et unikt resultat?
Det første kast er unikt - med en sandsynlighed på 3,6G/3,6G, og så der er 99999 kast tilbage.
Kast 2 er med (3,6G-1)/3,6G sandsynlighed unikt.
Kast 3 er med (3,6G-2)/3,6G sandsynlighed unikt.
.
.
.
Kast 100000 er med (3,6G-99999)/3,6G sandsynlighed unikt.
Alle disse sandsynligheder "ganges sammen", hvilket giver 24,94% sandsynlighed for, at alle "kast" er unikke - og således, at der ved 100k logins over en time med 3,6G unikke timestamps med små 25% sandsynlighed ikke vil være sammenfald.
Det er et spørgsmål om kombinatorik - lidt som arne_v nævner vedr. fødselsdags"paradokset", og regnestykket skrives således:
s = 3,6G
n = 100k
s!/(n-1)!/s^n - eller som produktet af (s-x)/s, med værdier af x fra 0 til n-1.
#64 << Det er ikke relevant, hvor serveren starter efter genstart, da alle sessioner alligevel tabes ved genstart. I øvrigt kan serveren let holde styr på, hvortil den er nået.
Du kan da ikke kombinere ved at gange n/2 med n-1 - ikke mindst kolliderer værdierne ikke kun parvis.
#65 << UUID kolliderer "ikke" - og i øvrigt sætter man altid unik-flag på rækken med UUIDs og errorhandling ved konflikt, så problemet kan højest blive teoretisk.
rmariboe (72) skrev:Sådan en fejl må altså aldrig opstå - og selv hvis der er så uskolede udviklere på holdet, bør fejlen fanges under QA! (Og hvis der ikke er grundig QA på et projekt af den vigtighed...)
Den her type fejl fanges næppe af QA. Den skal fanges ved code review.
rmariboe (72) skrev:Det er ikke relevant, hvor serveren starter efter genstart, da alle sessioner alligevel tabes ved genstart.
Det afhænger jo af hvorvidt man bruger session replikering eller ej.
Givet brug af WebSphere AS er session replikering absolut en mulighed. Det skal bare slåes til.
rmariboe (72) skrev:I øvrigt kan serveren let holde styr på, hvortil den er nået.
Så er man jo tilbage ved en persisterings løsning.
rmariboe (72) skrev:UUID kolliderer "ikke"
Det er ikke sandsynligt.
Men om man kan leve med en så minimal risiko er noget man må vurdere.
rmariboe (72) skrev:og i øvrigt sætter man altid unik-flag på rækken med UUIDs og errorhandling ved konflikt, så problemet kan højest blive teoretisk.
Det kan man jo også med timestamp. Der er ingen forskel på det.
Men problemet ligger jo nok i at data ikke skulle bruges som værdi i en tabel.
#73, "Den skal fanges ved code review." << Code review ikke den første del af QA? :)
"Det afhænger jo af hvorvidt man bruger session replikering eller ej" << Jeg mente egentlig blot, at alle sessions tabes, idet de ikke skal skal anvendes - og ellers kommer løsningen, som vi henviser til; sessionsreplikering eller blot persistens.
"Det kan man jo også med timestamp." << Men der er noget større sandsynlighed for kollisioner, hvorfor der potentielt bør bruges mere udviklertid på error handling.
Forslaget med inkrementering ville jeg klart hælde til, såfremt ID holdes i tabel og udelukkende benyttes internt - UUID+timestamp for enhver eksponeret brug. Jeg tror, at sandsynligheden (yes, pun intended:) for, at ID gemmes i en tabel, er 1 - ikke mindst idet sessionen mig bekendt benyttes på tværs af flere systemer.
"Det afhænger jo af hvorvidt man bruger session replikering eller ej" << Jeg mente egentlig blot, at alle sessions tabes, idet de ikke skal skal anvendes - og ellers kommer løsningen, som vi henviser til; sessionsreplikering eller blot persistens.
"Det kan man jo også med timestamp." << Men der er noget større sandsynlighed for kollisioner, hvorfor der potentielt bør bruges mere udviklertid på error handling.
Forslaget med inkrementering ville jeg klart hælde til, såfremt ID holdes i tabel og udelukkende benyttes internt - UUID+timestamp for enhver eksponeret brug. Jeg tror, at sandsynligheden (yes, pun intended:) for, at ID gemmes i en tabel, er 1 - ikke mindst idet sessionen mig bekendt benyttes på tværs af flere systemer.
rmariboe (72) skrev:I øvrigt må "mikrosekund" være en fejl, idet uret kun leverer milisekundopløsning.
Nu ved jeg ikke hvilken maskine de kører på.
Men rigtigt mange helt almindelige PC'ere understøtter faktisk tid ned til mikro sekunder.
Win32 API QueryPerformanceCounter kaldet kan hente den mest præcise tid som hardwaren kan levere. Den præcise granularitet afhænger af hardwaren, men mange kan gå ned til mikrosekunder.
I Java er det nemt via at hente oplysningen via System.nanoTime().
#76 << Ja, processoren tæller fint ned til µs eller mindre - men (CMOS) uret leverer almindeligvis stadig kun ned til ms.
Som du selv påpeger, får du i øvrigt tit pseudopræcision retur; i praksis en mindre præcision med en række nuller tilføjet.
Idet Skat er en offentlig institution, ruller de sandsynligvis på Dellgrej, da det oftest er billigst.
http://mariboe.net/3,6G-200k.jpg viser i øvrigt sandsynligheden fra 0 til 1 for 100% "unikhed" (unicitet?) ved fra 1 til 200k "kast" med 3,6G-"sidet terning".
Edit: Hmm, jeg googlede og fandt henvisning til patent, som omtaler "Because the maximum frequency of a CMOS RealTime Clock can be as high as 8192 Hz", og en adjtimex-man page, som omtaler µs-nøjagtighed.
Som du selv påpeger, får du i øvrigt tit pseudopræcision retur; i praksis en mindre præcision med en række nuller tilføjet.
Idet Skat er en offentlig institution, ruller de sandsynligvis på Dellgrej, da det oftest er billigst.
http://mariboe.net/3,6G-200k.jpg viser i øvrigt sandsynligheden fra 0 til 1 for 100% "unikhed" (unicitet?) ved fra 1 til 200k "kast" med 3,6G-"sidet terning".
Edit: Hmm, jeg googlede og fandt henvisning til patent, som omtaler "Because the maximum frequency of a CMOS RealTime Clock can be as high as 8192 Hz", og en adjtimex-man page, som omtaler µs-nøjagtighed.
#77 << Damn, "Ret indlæg" virker ikke så godt i dag - ville gerne have tilføjet, at man pagen påpeger, at
"Your computer has two clocks - the "hardware clock" that runs all the time, and the system clock that runs only while the computer is on. Normally, "hwclock --hctosys" should be run at startup to initialize the system clock. The system clock has much better precision (approximately 1 usec), but the hardware clock probably has better long-term stability."
- jeg ved ikke, hvordan eller hvornår, "system clock" stilles; men mon ikke, der blot henvises til, at CPUens counter kan benyttes som ur med "hardware clock" som reference?
"Your computer has two clocks - the "hardware clock" that runs all the time, and the system clock that runs only while the computer is on. Normally, "hwclock --hctosys" should be run at startup to initialize the system clock. The system clock has much better precision (approximately 1 usec), but the hardware clock probably has better long-term stability."
- jeg ved ikke, hvordan eller hvornår, "system clock" stilles; men mon ikke, der blot henvises til, at CPUens counter kan benyttes som ur med "hardware clock" som reference?
Øhh er jeg den eneste der kun laver ID for at det skal være unikt? lol. Hva fanden er meningen med et ID hvis det ikke er unikt?
Alle kodere laver fejl, enig, men det er i "test"-processen hvor fejl er acceptable. Når det lanceres fra beta til stable version skal det skuda også virke? Om de har en dårlig dag eller ej vil jeg da skide på, det er da helt til grin.
Hvis de ikk kan gøre deres arbejde ordentligt må de sku finde nogle andre. Hvis jeg har med amatøre at gøre så får de sparket og jeg går videre til nogen der kan finde ud af det.
Men hey, SKAT er jo ligeglade, for jo mindre det koster dem jo flere af vores hårdtjente penge kan de bruge på ligegyldigt crap. Fuck jeg glæder mig til at flytte fra det her skod land snart ...
Hyhan (18) skrev:Hmm... Jeg kan lige som fornemme på det hele, at jeg sidder med de meget få promiller af software udviklere i verden der lever i sus og dus herinde. Jeg mener folk der kan udvikle så komplekse app uden at lave fejl...Det er godt nok flot.
Vi kan hurtigt blive enige om at det burde have været en fejl der ikke skulle have opstået. Men har selv siddet med software udvikling i 12år nu. Men jeg laver da også stadig fejl en gang imellem... Man har vel også sine dage hvor hovedet ikke kører 100%? Eller er det kun os mennesker der har det sådan?
Alle kodere laver fejl, enig, men det er i "test"-processen hvor fejl er acceptable. Når det lanceres fra beta til stable version skal det skuda også virke? Om de har en dårlig dag eller ej vil jeg da skide på, det er da helt til grin.
Hvis de ikk kan gøre deres arbejde ordentligt må de sku finde nogle andre. Hvis jeg har med amatøre at gøre så får de sparket og jeg går videre til nogen der kan finde ud af det.
Men hey, SKAT er jo ligeglade, for jo mindre det koster dem jo flere af vores hårdtjente penge kan de bruge på ligegyldigt crap. Fuck jeg glæder mig til at flytte fra det her skod land snart ...
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund