A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Here's my problem. My application is ASP.NET/C#, the requirement is something like this:
1. About 100-200 users of the site
2. The ASP.NET server also talks to some back-end processes and time to time receives a message
3. The message needs to be "broadcast" - i.e., every operator who logs in, or is in any page, should see a "popup"
I've managed to do the popup/show in any screen etc. by use of AJAX etc. That's not what I want to hear suggestions on.
My algorithm is something like this:
When browser "polls" the server (via a XMLhttpReq)
The lifetime of a message in the server is, say, x minutes per user (it has to be shown to every logged in user, but within the x minutes, or the message expires)
To do this, I need a combination of logged in users, the list of messages, which users have seen the message and so on. I'm not happy with my hashtable/cache implementation - so I wanted to know if enlightened JoS readers have suggestions, and what kind of C# data structures could be good help in building a composite helper class? (queues? NameValueCollections? etc. etc. )
Do you have to guarantee that every user sees the message, even if they aren't logged in at the time?
It seems to me you'd only need a bit in session state that says if they've seen the message. If the bit isn't there, then pop up the message, and add the bit to session state to prevent it.
What is supposed to happen after the user logs out, and then logs in again before the message expires? If it's ok to pop the message up again, that's all you need. If not, well, something else has to store the user->seen message listing.
You might also like to consider a scheme along these lines:
- each message has a unique "number". It might be an integer, or it might (possibly) be data time based. In any case, the id is assigned by the server, and ID's increase - i.e. each new message has an ID greater than the last (it doesn't matter how much greater, as long as it is greater).
- When the client polls the server, it says, "here is the ID of the last message you gave me, do you have anything more recent?"
So instead of this:
you have this:
if(messageIDFromClient < lastMessageIDAllocatedByServer)
ReturnToClient(...all messages with ID's greater than the ID just recieved from the client ...)
If that suits you situation, it could simply things a lot. You end up with basically no state tracking on the server - the "who has seen what" tracking is just driven of the fact that each client knows the ID of the last message it has recieved.
It also makes for efficient polling, since the request is always small (just a message ID) and the response is small (even empty) if there is no new message for the client.
Tuesday, August 23, 2005
Sounds like a job for the Observer pattern:
Wednesday, August 24, 2005
Interesting thought - I need to ponder over it some more. There are several issues I need to take care of - for e.g. users can switch between pages. A message can be sent from 1 to n users within time 'X' etc. So I need to look closely at your idea, it's pretty cool though!
I'll let you know if I borrowed from it!
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz