Jump to content

SSB via T-Mobile cellphone


Guest
 Share

You are about to reply to a thread that has been inactive for 2944 days.

Please take a moment to consider if this thread is worth bumping.

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?

 

Link to comment
Share on other sites

  • Replies 105
  • Created
  • Last Reply

Top Posters In This Topic

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

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


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


$ 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

  • Lindens


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

 

Link to comment
Share on other sites

  • Lindens

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

  • Lindens


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

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

  • Lindens

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

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

  • Lindens

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

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

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

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

  • Lindens

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

You are about to reply to a thread that has been inactive for 2944 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...