Well, I think your're facing conceptually the same problem that you have in php/apache with sessions.
You have a stateless environment, where each request is handled by the server, the response is sent and all state is lost. In php, session data is stored in file by default (but could be stored in a DD.BB). When the client opens a session, the server generates and returns a piece of data that will allow the client to identify himself in following requests. But, since the server itself doesn't track the client, you have to set some expiration time for the session. Maybe you could do something similar. When a logged-in user sends a request, you store a lastActivity timestamp in the database (you can add a field in the activeUser table, since you already have it). At some point, you check that table and remove all users whose lastActivity field is older than some threshold value. There are a number things you should tune if you follow this path. For instance, you have to decide when to store the timestamp and when to check for unconnected users. If it doesn't hurt performance (and if you have a limited number of users, I think it wouldn't) maybe you could store the timestamp each time the client polls the DD.BB, and check for unconnected users at the same time. In that case, your time threshold could be small. Assuming, for instance, that you poll the DD.BB. every 5 seconds, you can consider disconnected a client that doesn't show activity in, say, the last 20 seconds (I think it's a safe ratio, but again, tuning this would require testing the actual thing). Another option would be checking for disconnected clients with a longer interval and using a bigger threshold to consider a user disconnected. It's a trade-off. You'd lose accuracy, but the DD.BB would be less stressed (consider that each client will be performing these queries). Cheers Juan Pablo Califano 2009/1/10, Omar Fouad <omarfouad....@gmail.com>: > Yes Pablo, that is an issue that I am being thinking about today. I want to > enable user presence detection to the client. > I've been thinking to let each client logged to the chat, send it's "id" to > a table called ActiveUsers. When the user Closes the Application, the row > is > deleted. At the same time, the application intervally queries the table to > see what users are online. This is a good Idea, but there is a problem. > What > if the connection is cut, or the application is closed by an "end task" > command or by the system? How would I update the table and delete the user > from it? > > > > On Sat, Jan 10, 2009 at 2:40 PM, Juan Pablo Califano < > califa010.flashcod...@gmail.com> wrote: > > > I think you could do take the same approach as in an "http" chat system > > (i.e., not a real chat solution but I've seen it used when data push from > > the server was not available thru FMS, Red5 or other) > > > > You have at a minumun 2 tables: users and messages. > > > > When the user logs in, it's inserted into the users table and an id (such > > as > > an autoincremental) is returned for using in further requests. > > > > In the messages table you have these fields: > > messageID > > senderID > > recipientID > > delivered. > > > > Have each client polling the DD.BB <http://dd.bb/> at a regular (and > > reasonable interval) to get a list of available users (you can pass the > > data > > you need here, but the only realy necessary part is the userID). > > > > Each time a client polls the DD.BB <http://dd.bb/>. it also asks for > > pending > > messages (which could be a text message or whatever you need; not sure if > > SQLite supports BLOB fields, but if it does you could store serialized AS > > objects, I guess). > > > > A pending message is just any message that has the user's userID and the > > delivered flag set to 0. If there's any matching that criteria, return it > > to > > the user. > > > > When a client wants to send a message, it does an insert in the messages > > tables, passing the recipient userID (which you can grab from the users > > list > > you already have), it's own ID and a message. > > > > You could also put a timestamp in each record (both in users and messages > > tables) an every time a user logs in, delete any record whose timestamp > is > > >= 24 hs old. > > > > For many scenarios, this would a problematic approach (you don't have a > > central server managing users interation, too much resposibility on the > > client, etc), but under the circumstances, I think it should work fine. > > > > Cheers > > Juan Pablo Califano > > > > > > > > > > 2009/1/10, Anthony Pace <anthony.p...@utoronto.ca>: - Ocultar texto > citado > > - > > > > > If you have ever run into problems when writing a file on the network > > when > > > someone else is trying you will know what I mean, and now just imagine > > that > > > you have an app requesting a write multiple times per second... there > is > > no > > > reliance. > > > > > > Nifty solution for the short term; yet, not something that can be used > > > reliably. > > > > > > I might be wrong; yet, I doubt it. > > > > > > scenario 1... user1 opens the db file to put in their message; yet, > user > > 2 > > > opened the file for writing just a milisecond before me, but it took > your > > > request for a write longer to reach the file server than mine did > > > > > > this would result in user1's message being overwritten > > _______________________________________________ > > Flashcoders mailing list > > Flashcoders@chattyfig.figleaf.com > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > > -- > Omar M. Fouad - ActionScript Developer > www.omar-fouad.net > Cellular: (+20) 1011.88.534 > Mail: m...@omar-fouad.net > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege. It should not be copied, > disclosed to, retained or used by, any other party. If you are not an > intended recipient then please promptly delete this e-mail and any > attachment and all copies and inform the sender. Thank you. > _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
