?

Log in

No account? Create an account
Does anyone know why the checkfriends interval being sent back is… - LiveJournal Client Discussions [entries|archive|friends|userinfo]
LiveJournal Client Discussions

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

[Mar. 4th, 2005|04:45 pm]
LiveJournal Client Discussions

lj_clients

[thorshammer]
[mood |confusedconfused]
[music |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?
linkReply

Comments:
[User Picture]From: flushedphoenix
2005-03-07 06:35 pm (UTC)
you need to have a paid account for the interval to be less.
(Reply) (Thread)
[User Picture]From: foalstory
2005-03-07 06:44 pm (UTC)
his/her acct is paid per user info
(Reply) (Parent) (Thread)
[User Picture]From: thorshammer
2005-03-07 06:48 pm (UTC)
Actually it had expired for a day or two, during which I got the 36000 interval, now it is back to 120.
(Reply) (Parent) (Thread)
[User Picture]From: foalstory
2005-03-07 06:49 pm (UTC)
a ha! that makes sense then :)
(Reply) (Parent) (Thread)
From: piman
2005-03-07 06:46 pm (UTC)
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...
(Reply) (Parent) (Thread)
[User Picture]From: thorshammer
2005-03-07 06:48 pm (UTC)
I agree, that is supposed to be the philosophy according to the protocol.
(Reply) (Parent) (Thread)
[User Picture]From: boggyb
2005-03-07 06:52 pm (UTC)
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.
(Reply) (Parent) (Thread)
[User Picture]From: marksmith
2005-03-07 06:53 pm (UTC)
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. :)
(Reply) (Parent) (Thread)
From: piman
2005-03-07 08:54 pm (UTC)
Until paid users use broken clients.

Block the clients that cause problems, not the users trying to solve them.
(Reply) (Parent) (Thread)
[User Picture]From: theorb
2005-03-07 09:06 pm (UTC)
Better, track the average interval between checkfriends requests for a given user, and do not let it become less then some minimum.
(Reply) (Parent) (Thread)
[User Picture]From: marksmith
2005-03-07 09:23 pm (UTC)
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.
(Reply) (Parent) (Thread)
[User Picture]From: mcfnord
2005-03-08 04:31 am (UTC)
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.
(Reply) (Parent) (Thread)