• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Lock cookie value

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

seeing older posts, I found some solutions for lock cookie generation. In particular:

1) Using clock, by obtaining current milliseconds or nanoseconds
2) Using a progressive long number
3) Using a random number

In my opinion, each solution has pros and cons:

1) Two requests very very near can obtain the same lock cookie. In addiction, the lock number value can be "inferred" by client basing on previous calls to lock.

2) Same as 1), but in this case the client can infer the lock cookie value in a simplier way.

3) It seems the best choice, but there is a very far possibility that the Random class can generate two identical cookies.

What's your opinion about?
 
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I used System.currentTimeMillis() to generate the lock cookie.

In my case the chances of two clients making a call to this at the same time is very unlikely as the call is made within a synchronised block.

Chris
 
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Roby,

1) Two requests very very near can obtain the same lock cookie. In addiction, the lock number value can be "inferred" by client basing on previous calls to lock.


If you generate your cookie from within a synchronized context, there should be no cookie collision. If you use nano seconds, the risk of succesful client attacks with generated cookies should be very small.

3) It seems the best choice, but there is a very far possibility that the Random class can generate two identical cookies.


If you're interested in another way to generate random numbers, have a look at the java.util.UUID class which allows random UUID creation and conversion into long values.

Regards,
Thomas
[ September 27, 2008: Message edited by: Thomas Thevis ]
 
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am using System.nanoTime() to generate the cookie value. I feel that the chances of two client getting the same cookie value is very small in this case. By the way: keep in mind that this is just an example application. It does not have to be completely perfect, you just have to demonstrate that you get the basics of developing a Client / Server application. If you justify you decisions in your choices.txt you should be fine.
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, different approaches have their advantages and disadvantages, but a combination of two approaches can eliminate the disadvantages. In my project, I used a combination of these two strategies

2) Using a progressive long number
3) Using a random number

I simply combined a progressive long number (a counter that was incremented each time) with a random number. The random part and the consecutive counter part were in different bit ranges of the long number. That way

a) the (anyway very small) likelihood that by accident the same cookie value is generated twice goes down to zero because in addition to the random part, a progressive number is used (with a random long value, the likelihood of the same value being generated twice is actually so low that we might not have to care, but still it is theoretically possible)

b) because of the random part, a malicious client cannot guess cookie values

Such a combination of two strategies that eliminates their disadvantages is probably not really required, but I found it made sense.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic