Yeah that is what I wanted to do... But as you said I have to tune the Timings.
I'll try it out and let you know.. Thanks for the help. Cheers. On Sat, Jan 10, 2009 at 11:11 PM, Juan Pablo Califano < [email protected]> wrote: > 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 <[email protected]>: > > > 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 < > > [email protected]> 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 <[email protected]>: - 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 > > > [email protected] > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > > > > > > > -- > > Omar M. Fouad - ActionScript Developer > > www.omar-fouad.net > > Cellular: (+20) 1011.88.534 > > Mail: [email protected] > > > > 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 > > [email protected] > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > -- Omar M. Fouad - ActionScript Developer www.omar-fouad.net Cellular: (+20) 1011.88.534 Mail: [email protected] 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 [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
