||[Mar. 4th, 2005|04:45 pm]
LiveJournal Client Discussions
|||||Sukilove (You Kill Me): Girl On The Moon||]|
Does anyone know why the checkfriends interval being sent back is 36,000 seconds (aka 10 hours)?
Is it possible they switched to microseconds and didn't tell anyone, or do they not want clients using the checkfriends protocol anymore?
you need to have a paid account for the interval to be less.
his/her acct is paid per user info
Actually it had expired for a day or two, during which I got the 36000 interval, now it is back to 120.
a ha! that makes sense then :)
That seems to defeat the point. checkfriends exists so people don't keep reloading their friends page over and over, taking up a lot of bandwidth. If you prevent the vast majority of accounts from using it, you just use that much more bandwidth...
I agree, that is supposed to be the philosophy according to the protocol.
I think it's because when checkfriends was first introduced it did something evil to the server load, and fingers got pointed at a certain popular client that wasn't obeying the checkfriends spec. I don't know if that client now behaves itself.
Nah. Bandwidth isn't really the issue. Database load is, and checkfriends is about the heaviest part of the whole process. With millions of free users, it was bogging down the system quite a bit, so now it's a paid user feature.
It wouldn't have been a problem if clients were implemented properly, but most clients just check as fast as the server allows -- even if the user hasn't acknowledged the last notice. So, overnight, the client is checking every 2 or 3 minutes, every hour, even though the user isn't at their computer. Quite inefficient.
So the decision was made to limit it to paid accounts. We can't change the clients, but we can change the server to make things work out anyway. :)
Until paid users use broken clients.
Block the clients that cause problems, not the users trying to solve them.
Better, track the average interval between checkfriends requests for a given user, and do not let it become less then some minimum.
Nah, paid users use broken clients all the time. But they're paying, so we're not going to disable access unless there's a dire problem.
Same logic for putting free users read-only at times on Filet Mignon, yet the paid users never get put read-only. If you reduce the load on 95% of the userbase, then the 5%, even if they're doing something broken, aren't going to really affect things.
You could take a pro-active approach to the quality of client data practices by publishing client load stats and then encouraging people to keep their app resource usage down. This lets you communicate your values, influence client development efforts, and ultimately provide additional room for new tools within the resource pool.