IMPORTANT EDIT: I found that the problem is not what I thought it was, and the error should now be easy to reproduce. The problem occurs when the built-in edit journal privacy tool is used. I have edited this entry to reflect this fact, and removed misleading references to the problem occurring on "large journals."
When the LJ-SEC tool tries to download my journal history (via a syncitems request) the server never responds.
I created a simple test journal to determine the cause:
oak_and_sage. This journal has only seven entries. I did many things to this journal, and tested LJ-SEC after each one; the syncitems call began timing out immediately after I used the built-in edit journal privacy tool to change all public entries to friends only.I've done a little debugging (since LJ-SEC is open source) to determine what's going on. The server is failing to respond to the initial syncitems call (when it has never done a sync before).
Here is the LJ-SEC code to transmit a web call to LJ:
private string LJWebCall(string strCall)
{
string Response = "";
string Cookie = "";
const string RequestMethod = "POST";
NameValueCollection collHeader = new NameValueCollection();
// Initiate initial try to get challenge
httpc = new HttpBaseClass(
conf.GC.ProxyUseLogin ? conf.GC.ProxyUserName : "",
conf.GC.ProxyUseLogin ? conf.GC.ProxyPassword : "",
conf.GC.ProxyURL,
conf.GC.ProxyPort == "" ? 0 : Convert.ToInt32(conf.GC.ProxyPort),
strCall);
try
{
// No redirects expected for now
HttpWebRequest webrequest =
httpc.CreateWebRequest(conf.GC.LJLoginURL,
collHeader, RequestMethod, conf.GC.ProxyUseLogin);
Response = httpc.GetFinalResponse(conf.GC.LJLoginURL, Cookie,
RequestMethod, conf.GC.ProxyUseLogin);
}
catch (System.Net.WebException e)
{
MessageBox.Show("Error connecting to the web server!\nError message:" + e.Message);
}
This is called via this method:
private string GetSyncItems(DateTime syncdate)
{
return LJWebCall("mode=syncitems&user=" + conf.GC.LJUserName
+ "&auth_method=challenge&auth_challenge="
+ LJChallengeString + "&auth_response=" + HashPassword
+ "&ver=1&lastsync=" + syncdate.ToString(Program.EnforcedDateFormat)
+ (conf.GC.LJCommunity != "" ? "&usejournal="
+ conf.GC.LJCommunity : ""));
}
...which is called via a much longer and more complex method that I won't duplicate here, but the important thing is that when I monitor the client program, it sends "getchallenge", logs in, sends "getchallenge" again, then sends the first syncitems request. The server never responds to the syncitems request (within the given time limit, which is, I believe, 100 seconds).
I wrote a log of the timed-out transmission (on
sithjawa) to a file. Here's what I found.Headers: Content-Type: application/x-www-form-urlencoded User-Agent: LJ-SEC client: version 0.71.3132.28957 Timeout:100000 Request URI: http://www.livejournal.com/interface/flat Request String: mode=syncitems&user=sithjawa&auth_method=challenge&auth_challenge=[I REMOVED THIS]&auth_response=[I REMOVED THIS]&ver=1&lastsync=0001-01-02 00:00:00Z
It's probably not necessary to have removed the auth info, but I'm paranoid.
There were no stored cookies.
The error message specified by the C# System.Net Exception is:
The operation has timed outIs this expected behavior? What should be done to prevent it?
EDIT: I found the following in the protocol guide: (link to actual page in the guide)
syncitems. If you are trying to download someone's entire journal, this is the mode to use. This mode is the only way you can account for edits that the user has made to their entries without using your client. This is also the most efficient way of downloading entries, because the server will send you a bunch at a time (say, 100). This mode is used in conjunction with the appropriately titledsyncitemsclient protocol mode.
Looking at the LJ-SEC code, it appears to be following the procedure outlined in the pseudocode example for properly downloading all items in a journal. This makes the timeout even more puzzling.