• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Cookie Generation [URLyBird]

 
Don Burke
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

i've hit another snag in my design. My take on the cookie is that it represents an unique identifier for each client using the server.

On connection to the server, the client will be sent a uniquely generated cookie (basically an ID) from the server, which it will then store as a constant.

I'm using a thick client so my business methods are contained client-side. The cookie will be used for any call to server methods that require the cookie.

When it comes time to lock records, the server will maintain a map of record # --> cookie.

Locking has been the most difficult issue for me on this assignment. I'm really a newbie at concurrency issues. I would like to hear your comments on this approach, constructive criticisms are welcome.

--

another thought i just had was is it possible to use the thread id of the client as the cookie?

thanks for any input

Don
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Don,
In my interface provided by Sun (URLyBird 1.2.1):


So, in this case, cookie does not represent "an unique identifier for each client using the server", it's a way for authenticating the client who holds the lock.

Each version of the assignments differs from the others,
Could you show us the interface provided by Sun you have to implement? and
what is your assignment version?

Regards, Ori
 
Marcio Aun Migueis
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don

Did you see the recent Jesse post ?
1. I uses a static Random long seed initialized once JVM started, as a seed of looked cookie generation.


I think it could be usefoul for you.

M�rcio
 
Don Burke
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,

my interface for the lock method is basically the same (Same comment).



Its interesting that some people are returning a random long from this method.

Jessie said: I used a static Random long seed initialized once JVM started, as a seed of looked cookie generation.


What if the same # is generated twice.. Wouldn't it be safter to have the lock method generate a unique id?..most likely through a counter.
I'm not quite sure what Jessie means by 'as a seed'. Am i missing something?

A drawback of using a counter would be that eventually the counter would overflow, so it would need to be reset at some point.

Also what about using the currentThread's ID as the cookie? Wont that always be unique?

On an aside i must say thanks to Oricio, you made me focus more attention on the lock method which clearly states that my previously mentioned would have broken the specs

Let me know what you think

cheers

Don
[ November 01, 2005: Message edited by: Don Burke ]
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello again,
There have been lots of discussion about cookie generation in this forum.
I think a good starting point is ask yourself: what is the propose of cookies in our asignment? A security issue? A way to force us to follow a specific design path?
Of course IMO it's a way to face and solve unclear specs.
Search the forum and you'll find good arguments for each position: Random cookie, incremental cookie, or recordNumber cookie.
Personally i generate a random long cookie with 32 bits related to the recordNumber, but i think now it's a historical decission in my design rather than the best election.
But one thing must be clear: it's the server who gives the cookies to the client that locks a record. And it's the client who needs that cookie if he wants to update the database. Only a client can hold a lock at the same time. And only the client who holds the lock (knows the correct cookie) can release it.
All that can be known from the interface provided.

... the counter would overflow ...

Are you sure?


Regards, Ori
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Krzysiek,

you are right, but you cannot read my lines outside of this context:
Don wrote:

... On connection to the server, the client will be sent a uniquely generated cookie (basically an ID) from the server, which it will then store as a constant ...

I only was trying to make him understand within his own design.
Anyway you can read those lines thinking in "server" as object who serves data access services and "client" as the requester object.

... And i'm one of those who choose the 3 tier design

Regards, Ori
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Krzysiek? my WC friend what have you done with your post?
[ November 02, 2005: Message edited by: Oricio Ocle ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Don,

Got a bit of beer money over the last couple of days, how 'bout you?

Originally posted by Don Burke:
What if the same # is generated twice.. Wouldn't it be safter to have the lock method generate a unique id?..most likely through a counter.


Is that likely though?
From the API for Random.nextLong():
Returns the next pseudorandom, uniformly distributed long value from this random number generator's sequence. The general contract of nextLong is that one long value is pseudorandomly generated and returned. All 2^64 possible long values are produced with (approximately) equal probability.
So you have an approximately equal probability of getting any number in the range of -9,223,372,036,854,775,808L to 9,223,372,036,854,775,807L! I think the chances of getting the same number twice amongst such a large range is fairly low, and it would be extremely difficult to deliberately write malicious code to try and exploit this.

If you were still worried about it, you could look at the SecureRandom class.

Regards, Andrew
[ November 02, 2005: Message edited by: Andrew Monkhouse ]
 
Tomas Varsavsky
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll throw in my 2c since I think I implemented cookies a bit different to everyone else.

I have a service (singleton) called a CookieBroker that is in charge of issuing and tracking cookies. The Data class requests a cookie in lock() and returns it in unlock(). The cookies themselves are generated using Math.random(), but guaranteed to be unique because the CookieBroker checks that the cookie does not already exist. So far, pretty standard. Here's where the difference is: the cookies can time out after a configurable period (set to 60 seconds). When the cookie times out, the CookieBroker notifies the cookie holder via a callback. The Data class subscribes to this callback, and automatically releases the lock on any record that has timed out. The purpose is to remove the possibility of a record remaining locked for any reason.

This approach fits in with my design decisions:
(a) Thin client / 3 tiered architecture
(b) Client is unaware of locking
(c) Locking of records should be very short events. i.e. lock, do something with the record, unlock sequence should be very short (a few milliseconds)

I just got my results yesterday, 372/400, 80/80 for locking. I lost most of my marks in the networking, don't know why because I thought that was the most straightforward part of the assignment.
 
Don Burke
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All very good replies, thanks for the input!

Its clear that either of the above mentioned techniques are suitable for this assignment. I think i will use a combination of random long generation with the added insurance of cross-checking the result against existing cookies alreayd in use.

I dont like the idea of writing code that could potentially not work - even tho, in this case, it might never break, not even in a million years.

[its almost friday ]

cheers

Dan
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic