Wait 0.5 seconds and retry, 2 times, wait 0.4 seconds and retry, 3 times, wait 0.3 seconds and retry, 4 times, wait 0.2 seconds and retry, 6 times, wait 0.1 seconds and retry, ? times.
On Mon, Nov 12, 2012 at 1:21 PM, Charles Mills <[email protected]> wrote: > 1. A given PassTicket may only be used once (source > http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom. > ibm.cics.ts31.doc%2Fdfht5%2Ftopics%2Fdfht516.htm) > > 2. The PassTicket algorithm is deterministic: given the same time of day > (resolution one second), the same userid, the same application ID, and the > same secured signon application key, the algorithm will always produce the > same PassTicket (experimentation reveals this to be true). > > Consider a distributed application. Some large number of automated clients > sign on to some service at quasi-random intervals. A perfect application for > PassTickets, right? But if a second client tries to log on within the same > TOD second as an earlier client, the sign-on will be rejected because the > generated PassTicket has already been used. What is the client to do? The > obvious answer is "wait a second and try again" but that approach has some > obvious shortcomings, one of which being there is no guarantee that THAT > PassTicket has not already been used. > > Yes, one solution would be a unique userid for each client, but suppose this > is some "mass image rollout" application or there is some other reason why > unique userids are not desirable. > > What to do? > > Charles > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
