Jump to content
Sign in to follow this  
Guest

SSB via T-Mobile cellphone

Recommended Posts


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.
sigh

Could it be added as a normally "off" debug setting with a clear note on the when, why, where, etc for using?

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites


$ 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

Share this post


Link to post
Share on other sites


Sarah Passerine wrote:

So, it appears that the length and range headers are in disagreement with the curl grab of
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...

 

Share this post


Link to post
Share on other sites

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;

Share this post


Link to post
Share on other sites


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.

 

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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....

 

Share this post


Link to post
Share on other sites

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!!!

 

 

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!!!!! 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...