Perrie Juran Posted September 27, 2013 Share Posted September 27, 2013 Monty Linden wrote: Sarah Passerine wrote: For what it is worth, I bit the bullet and compiled my own viewer with a hack to work around this problem. I suspect the server is sending the correct headers, but our data providers are modifying it in the middle somewhere. For those with the know-how, edit: _httppolicy.cpp At line 353, add // If partial content, try to use it anyway, because Content-Length header can't be trusted. if (! op->mStatus) { if (op->mStatus.toString() == "Transferred a partial file") { op->mStatus=HttpStatus(); } } Interesting experiment. I'd suggest this change to make it more resilient to changes: // If partial content, try to use it anyway, because Content-Length header can't be trusted. if (! op->mStatus) { if (op->mStatus == HttpStatus(EXT_CURL_EASY, CURLE_PARTIAL_FILE)) { op->mStatus=HttpStatus(200); } } There is a maintenance fix coming that will make PARTIAL_FILE a retried error. But that doesn't help this situation. The challenge is that some people have the reverse problem: they *do* get short data and by retrying on this error, the error will clear and they will get the correct, complete texture The only single solution is to fix the carriers. sighCould it be added as a normally "off" debug setting with a clear note on the when, why, where, etc for using? Link to comment Share on other sites More sharing options...
Sarah Passerine Posted September 27, 2013 Share Posted September 27, 2013 Thanks a lot for the more refined code! It took me a while to trace exactly where I could inject a little hack, and that spot does the trick perfectly for me. But yes, I understand it can't be in the general viewer, as that error is legitimate for others. When it comes to the carriers getting their act straight, I'm not really going to hold my breath. A debug setting, as was suggested, may be nice in this case, to give others with this problem a way to pick their poison. An even better way to handle this might be to tweak libcurl so that if it notices a content length header that is set to its maximum possible value, it will assume it is a bogus number, and not flag the partial file error. Link to comment Share on other sites More sharing options...
Lindens Monty Linden Posted September 27, 2013 Lindens Share Posted September 27, 2013 I'm going to give the debug setting some thought. A loose/strict mode selector. I'd still like the 'curl' command tests against example.com though... Link to comment Share on other sites More sharing options...
Bunderwahl Guisse Posted September 28, 2013 Share Posted September 28, 2013 I dont really think the only or best option is fixing the carriers.. that is just not likely to happen. What we know for the people with this problem is the following (these may vary a little from one to another): 1. Sl performed well before sunshine. 2. It may work again for brief periods 3. All other aspects of SL still function, most importantly downloading of other textures 4. Sunshine "broke" something for them and they do not receive the baked textures. What this seems to suggest is that it is not the texture or the connection causing the problems, it was a change in delivery introduced with sunshine. All sunshine does (correct me if I am wrong) is bake several textures and sends one, instead of sending all and having the users machine bake them. I would guess this helps performance by having the server send less information and people with older machines rez faster. What is different about the baked textures and "ordinary" textures that you can still get the latter? A texture is a texture right? Why can not the baked texture be sent like all the others? Link to comment Share on other sites More sharing options...
Darien Caldwell Posted September 28, 2013 Share Posted September 28, 2013 Bunderwahl Guisse wrote: I dont really think the only or best option is fixing the carriers.. that is just not likely to happen. What we know for the people with this problem is the following (these may vary a little from one to another): 1. Sl performed well before sunshine. 2. It may work again for brief periods 3. All other aspects of SL still function, most importantly downloading of other textures 4. Sunshine "broke" something for them and they do not receive the baked textures. What this seems to suggest is that it is not the texture or the connection causing the problems, it was a change in delivery introduced with sunshine. All sunshine does (correct me if I am wrong) is bake several textures and sends one, instead of sending all and having the users machine bake them. I would guess this helps performance by having the server send less information and people with older machines rez faster. What is different about the baked textures and "ordinary" textures that you can still get the latter? A texture is a texture right? Why can not the baked texture be sent like all the others? Well, that's not the only change that came about in this time period. There have also been a lot of work (by Monty, no conincidence) to streamline HTTP communications, like reducing the number of simultaneous connections, using proper HTTP headers, using Keep-Alive connections, etc, and that work is ongoing. While, it's probably good to make SL adhere to the strictest of HTTP standards, the reality probably is, most of the rest of the Internet doesn't always do so. So it's inevitable conflicts like this will arise. Personally, I have a feeling a balance will have to be struck between strict standardization and quirky compatibility. But it definitely sounds like in this case, wireless carriers are not playing nice. Link to comment Share on other sites More sharing options...
Sarah Passerine Posted September 30, 2013 Share Posted September 30, 2013 $ curl -H 'Range: bytes=0-33554431' -D headers.txt -o body.txt http://www.example.com/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 32.0M 0 1270 0 0 43 0 9d 00h 0:00:28 9d 00h 0 curl: (18) transfer closed with 33553162 bytes remaining to read $ more headers.txt HTTP/1.1 206 Partial Content Accept-Ranges: bytes Cache-Control: max-age=604800 Content-Range: bytes 0-1269/1270 Date: Mon, 30 Sep 2013 14:42:34 GMT Etag: "359670651" Expires: Mon, 07 Oct 2013 14:42:34 GMT Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT Server: ECS (atl/FCAA) X-Cache: HIT Content-Type: text/html Content-Length: 33554432 $ curl -H 'Range: bytes=0-33554431' -D headers2.txt -o body2.txt http://www.example.com/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 32.0M 0 1270 0 0 48 0 8d 02h 0:00:26 8d 02h 0 curl: (18) transfer closed with 33553162 bytes remaining to read $ more headers2.txt HTTP/1.1 206 Partial Content Accept-Ranges: bytes Cache-Control: max-age=604800 Content-Range: bytes 0-1269/1270 Date: Mon, 30 Sep 2013 14:47:09 GMT Etag: "359670651" Expires: Mon, 07 Oct 2013 14:47:09 GMT Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT Server: ECS (atl/FCAA) X-Cache: HIT Content-Type: text/html Content-Length: 33554432 Link to comment Share on other sites More sharing options...
Sarah Passerine Posted September 30, 2013 Share Posted September 30, 2013 So, it appears that the length and range headers are in disagreement with the curl grab of www.example.com as well. Link to comment Share on other sites More sharing options...
Lindens Monty Linden Posted September 30, 2013 Lindens Share Posted September 30, 2013 Sarah Passerine wrote: So, it appears that the length and range headers are in disagreement with the curl grab of www.example.com as well. Many thanks for doing this test. This is making far faster progress than trying to reproduce this internally. Yes, it pretty much points to the network infrastructure as being that bad party. That said, the request is a somewhat atypical way of getting a page. Perfectly legal and has well-defined behavior but atypical. (No 'Range:' header or 'Range: bytes=0-' would either be more typical.) We do rely on 'Range' working and that won't change. But for SSA, there is another hack that might fix this problem as well as keep the 'Partial File' retry for those suffering different network problems. Let me prepare something there... Link to comment Share on other sites More sharing options...
Lindens Monty Linden Posted September 30, 2013 Lindens Share Posted September 30, 2013 Monty Linden wrote: Let me prepare something there... The following is something Linden could do about this. It's a one-liner in lltexturefetch.cpp that could be tried instead of the change in llcorehttp. This has the effect of making large requests look like more typical GET operations. I'd be interested in knowing how well this works.... --- a/indra/newview/lltexturefetch.cpp Wed Sep 18 14:32:18 2013 -0700+++ b/indra/newview/lltexturefetch.cpp Mon Sep 30 15:39:14 2013 -0400@@ -1482,15 +1482,15 @@ << LL_ENDL; // Will call callbackHttpGet when curl request completes mHttpHandle = mFetcher->mHttpRequest->requestGetByteRange(mHttpPolicyClass, mWorkPriority, mUrl, mRequestedOffset,- mRequestedSize,+ (mRequestedOffset + mRequestedSize) > 20000000 ? 0 : mRequestedSize, mFetcher->mHttpOptions, mFetcher->mHttpHeaders, this); } if (LLCORE_HTTP_HANDLE_INVALID == mHttpHandle) { llwarns << "HTTP GET request failed for " << mID << llendl; Link to comment Share on other sites More sharing options...
Bunderwahl Guisse Posted October 1, 2013 Share Posted October 1, 2013 I would be happy to be a lab rat, just tell me what to do and I will do it Link to comment Share on other sites More sharing options...
Lindens Monty Linden Posted October 1, 2013 Lindens Share Posted October 1, 2013 Bunderwahl Guisse wrote: I would be happy to be a lab rat, just tell me what to do and I will do it Happy to have you in the lab. The warning is that this is one that's for people already comfortable with building the viewer from source. It's not a simple checklist process. Link to comment Share on other sites More sharing options...
Bunderwahl Guisse Posted October 3, 2013 Share Posted October 3, 2013 I pointed Jessica Lyon from FS to this thread, they may have the resources/know how to help Link to comment Share on other sites More sharing options...
Sarah Passerine Posted October 8, 2013 Share Posted October 8, 2013 I finally got a moment to make that change in lltexturefetch.cpp, and it works much better than the one in http policy, so far. Textures are loading, and doing so very quickly. Thanks! This might just be the thing that fixes it for other tethering users as well, and it would be wonderful to add it to the main viewer code. Link to comment Share on other sites More sharing options...
Lindens Monty Linden Posted October 8, 2013 Lindens Share Posted October 8, 2013 Many thanks for testing that out. We'll try to get that out. There may still be breakage because there is still something defective in the carriers' network. So, if you (or others, this may or may not fix their problems) see failures again, speak up. We may need to do more.... Link to comment Share on other sites More sharing options...
Elyse Sirnah Posted October 9, 2013 Share Posted October 9, 2013 laughs... Ok.. remember I am not technical at all (well maybe some but not enough) anyhow... is this someting that we will need to download an update for on our end? I've been gray for days now unless I log in with my phone.. so much so that I finallly broke down and contacted Verizon talked to a tier 2 tech person (what ever that means) and he checked out ther "provisions" (what ever they are) and all are set correctly and I shouldn't be having any problem... well according to him. I would love to be able to see again (without using my limited data causing overages).. it is horrible having a sim full of gray alien avi!!! Link to comment Share on other sites More sharing options...
Lindens Monty Linden Posted October 9, 2013 Lindens Share Posted October 9, 2013 Yes, this will be a viewer update at some point. It *may* fix your problem. But if this is a carrier-caused failure, there may be additional problems. If anyone is working with upper tiers of support at their carrier, I'd strongly suggest pointing them at two replies in this topic. The first gives them a test they can perform. They should replicate whatever setup you have (phone/wireless device, connection type, etc.): http://community.secondlife.com/t5/Second-Life-Server/SSB-via-T-Mobile-cellphone/m-p/2215959#M12043 And this reply shows what happens if they're doing something very wrong to HTTP: http://community.secondlife.com/t5/Second-Life-Server/SSB-via-T-Mobile-cellphone/m-p/2235061#M12155 What they need to check is that 'Content-Length' and 'Content-Range' are in agreement. The problem appears when they are not. Link to comment Share on other sites More sharing options...
Drake1 Nightfire Posted October 9, 2013 Share Posted October 9, 2013 I'm not trying to hijack this thread, but without any input i feel there will be a war either inworld or on the forums over the new ToS. There are two threads in question.. This one and this one.. please help. Link to comment Share on other sites More sharing options...
Bunderwahl Guisse Posted October 10, 2013 Share Posted October 10, 2013 Of ffs, not trying to hijack the thread? That is all you are trying to do. Your post has NOTHING to do with the problem disscussed. Link to comment Share on other sites More sharing options...
Bunderwahl Guisse Posted October 10, 2013 Share Posted October 10, 2013 Can someone help a brother out? While it looks like progress is being made and there is something that would fix my problem, it is looking like I am going to have to wait for a viewer upgrade, however long until the next one is out.. or possibly a later one. Can someone please just tell me what to do or copy the need file and send it to me? I rent an entire estate that is a role play sim (Dark Alley) and a SL tradition with a history approaching 6 years, it is a shame that I have not been able to enjoy it, and lack the desire to even log on since the last "improvment"(In July). I know this does not entitle me to any special trearment.. but come on.. we are talking several months to someone paying over 300 USD and providing entertainment to 500 plus visitors a day with traffic around 35K sans bots and campers. I know this does not entitle me to any special treatment but even a person on a free account should be able to enjoy SL Link to comment Share on other sites More sharing options...
Tonya Souther Posted October 10, 2013 Share Posted October 10, 2013 I'm going to add that to Firestorm and see what happens. Edit: I've added it as Firestorm Mercurial revision 38682. If it passes testing, it'll be in the next release of Firestorm. FIRE-11448 is the Firestorm JIRA entry for this issue; if you're interested, you can follow the progress there. Link to comment Share on other sites More sharing options...
Bunderwahl Guisse Posted October 11, 2013 Share Posted October 11, 2013 If you need/want someone to beta test it with the problem Tonya you can contact me in game, I would be happy to do so Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted October 12, 2013 Share Posted October 12, 2013 If anyone having this problem would like to test a build of Firestorm containing Monty's proposed fix, please drop me an IM inworld and tell me what operating system you are using. Bunderwahl, I already left you an IM. Those of you testing, please leave feedback for Monty on this thread for how the fix works for you. Link to comment Share on other sites More sharing options...
Bunderwahl Guisse Posted October 13, 2013 Share Posted October 13, 2013 On the FS beta.... it works (remote possibility it is a fluke: logged in could not see, downloaded Whirlys fex and relogged saw clothing immedietly. My experience has been failure in the high 90 percent range.. so could be a fluke) I do have to work tonight but initial conclusion is my problems are over. If there are any tests youo want me to do Monty say the word. Whirly ... thanks and like the new initial screen, seems sharper Link to comment Share on other sites More sharing options...
Lindens Monty Linden Posted October 13, 2013 Lindens Share Posted October 13, 2013 Only specific suggestions I have are: 1) do as many sessions as possible in regions with other avatars and 2) clear cache between sessions so textures must reload. This 2nd item will slow scene loading but is useful for testing. Once some testing is done, keep your cache, it's valuable. Link to comment Share on other sites More sharing options...
Elyse Sirnah Posted October 16, 2013 Share Posted October 16, 2013 I am warm and toatsy fresh out of the oven baked as are all my friends!!! YAY!! it seems to be working wonderfully!! Will update if I have any problems with the FS beta update!! Thank you Thank you Thank you!!!!! Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now