|
zozo
Dec 6, 2006, 11:35 PM
Post #1 of 23
(2081 views)
Shortcut
Registered: Feb 3, 2004
Posts: 3431
|
How exactly does embedding a picture in a thread with an absolute url impact rc's bandwidth?
So long as the pic is coming from another site of course.
|
|
|
|
|
rrrADAM
Dec 7, 2006, 1:07 AM
Post #2 of 23
(2058 views)
Shortcut
Registered: Dec 19, 1999
Posts: 17553
|
zozo wrote: How exactly does embedding a picture in a thread with an absolute url impact rc's bandwidth? So long as the pic is coming from another site of course.
Pictures require more data than text, so the "pipe" needed to squeeze the data through needs to be bigger, else the data (water) will come out slower. Hook more people up to the same pipe, demanding more data (water), and everyone only gets a trickle.
That's why on a dial-up (tiny pipe connected to the net) text comes through much quicker than pictures, and video takes even longer.
Actually, it may be quicker posting an image that's on the same server.
I'm not an expert, but I think that's an accurate analogy... I may be wrong.
(This post was edited by rrradam on Dec 7, 2006, 1:11 AM)
|
|
|
|
|
snoopy138
Dec 7, 2006, 1:57 AM
Post #3 of 23
(2043 views)
Shortcut
Registered: Jul 7, 2004
Posts: 28992
|
rrradam wrote: zozo wrote: How exactly does embedding a picture in a thread with an absolute url impact rc's bandwidth? So long as the pic is coming from another site of course. bandwidth = diamter of pipe: Pictures require more data than text, so the "pipe" needed to squeeze the data through needs to be bigger, else the data (water) will come out slower. Hook more people up to the same pipe, demanding more data (water), and everyone only gets a trickle. That's why on a dial-up (tiny pipe connected to the net) text comes through much quicker than pictures, and video takes even longer. Actually, it may be quicker posting an image that's on the same server. I'm not an expert, but I think that's an accurate analogy... I may be wrong.
I think the question is how this affects rc.com's servers, since the user is presumably pulling the picture from the site where it is hosted, and not rc.com.
|
|
|
|
|
jakedatc
Dec 7, 2006, 2:12 AM
Post #4 of 23
(2039 views)
Shortcut
Registered: Mar 12, 2003
Posts: 11054
|
yep... from another site.. different plumbing.. not our problem (and for sites like photobucket, flickr, etc the point is to use their site for just that)
kill videos.. embed images.. decrease bandwidth demands =happy rc users
|
|
|
|
|
climbsomething
Dec 7, 2006, 4:10 AM
Post #5 of 23
(2027 views)
Shortcut
Registered: May 30, 2002
Posts: 8588
|
Adam's analogy makes sense to me, but I am of limited expertise myself. But who the hell still has dial-up?? 
Early official new-site language also indicated that embedded images would be eliminated because it was not a part of the new rc.com "brand." I don't believe that had anything to do with bandwidth, though what exactly the "brand" is to otherwise consist of, I dunno.
|
|
|
|
|
coldclimb
Dec 7, 2006, 6:54 AM
Post #6 of 23
(2017 views)
Shortcut
Registered: Jan 14, 2002
Posts: 6909
|
I think the question is really rhetorical, as I believe Zozo knows the answer. The answer is that RC.com's bandwidth is not affected when the pics are hosted on other websites. A person downloads the pics from the other websites and their browser displays them as part of the page here. Same for advertisements and such, which is why if you watch your status bar really closely when you load a page like www.yahoo.com, it has a whole bunch of websites flash past.
The bandwidth excuse is one that doesn't hold water. The percieved "ugliness" reason is the only reason that can have any merit, and then ONLY from the owners' perspective, and apparently NOBODY else's. If bandwidth were an issue, videos would not be added. One video download makes up for a whole lot of photo downloads.
|
|
|
|
|
veganboyjosh
Dec 7, 2006, 8:02 AM
Post #7 of 23
(2010 views)
Shortcut
Registered: Dec 22, 2003
Posts: 1421
|
coldclimb wrote: One video download makes up for a whole lot of photo downloads.
technically, one video download IS a whole lot of photo downloads.
i miss photos.
this new rc.com branding sucks monkey balls. the brown monkey was better than this rc.com brand.
|
|
|
|
|
rrrADAM
Dec 7, 2006, 8:45 AM
Post #8 of 23
(2005 views)
Shortcut
Registered: Dec 19, 1999
Posts: 17553
|
snoopy138 wrote: rrradam wrote: zozo wrote: How exactly does embedding a picture in a thread with an absolute url impact rc's bandwidth? So long as the pic is coming from another site of course. bandwidth = diamter of pipe: Pictures require more data than text, so the "pipe" needed to squeeze the data through needs to be bigger, else the data (water) will come out slower. Hook more people up to the same pipe, demanding more data (water), and everyone only gets a trickle. That's why on a dial-up (tiny pipe connected to the net) text comes through much quicker than pictures, and video takes even longer. Actually, it may be quicker posting an image that's on the same server. I'm not an expert, but I think that's an accurate analogy... I may be wrong. I think the question is how this affects rc.com's servers, since the user is presumably pulling the picture from the site where it is hosted, and not rc.com.
From what I understand:
Everything still needs to travel through the pipes that come from our server.... In or out.
It is the hub from which the data (water) comes, so its bandwidth is the diameter of its pipes that lead in and out of it, the pipes may get smaller as they get to us through the internet, that is not the server's bandwidth but a product of how you are connected to the server through the Net. The smallest pipe between the hub and your computer and the flow through it and/or any other branch en route to you denote the speed with which you will get the data (water) out your faucet (computer).
Say there is one large pipe coming from the hub, and that pipe needs to supply everybody on rc.com at one time all the data they are asking for (entire pages, buttons, ads, text, pics, video, etc...), and the pipe can only hold so much volume, the onlly thing that can happen is the rate at which the data can flow through it must change in proportion to the demand on it. (Think about your water pressure in the shower when the washing machine is running, and someone flushed the toilet.... Or freeway traffic with each car being a packet of info, when more packets are requested and/or more people are asking for packets, the traffic slows, as there are only so many lanes.)
It would stand to reason that the more data (water) requested, the slower the rate.
Now imagine that our hub (server) has only one large pipe that shares input/output duties... Now the volume can be halved just by having to get data from sources outside the server (input) only to redirect it back through the pipe again on its way out.
Does this make sense ??? Gonna need a geek to tell me/us if its a correct analogy.
(This post was edited by rrradam on Dec 7, 2006, 8:57 AM)
|
|
|
|
|
coldclimb
Dec 7, 2006, 8:58 AM
Post #9 of 23
(1995 views)
Shortcut
Registered: Jan 14, 2002
Posts: 6909
|
It makes sense Adam, but I am reasonably assured that it's not the case. It COULD be the case if the site was designed that way... but why would it be designed to use more bandwidth? In general, unless built otherwise, your computer fetches the image from its host server, and rc.com simply says "It's over there ---->". The image does not go to rc.com, then to you, rc.com merelypoints you to it, your computer sends a request to that host and downloads the file, in addition to the stuff from the thread on rc.com, and your browser puts it all together and displays it.
Someone correct me if I'm wrong, but I'm certain this is right. 
(This post was edited by coldclimb on Dec 7, 2006, 9:01 AM)
|
|
|
|
|
melekzek
Dec 7, 2006, 9:02 AM
Post #10 of 23
(1991 views)
Shortcut
Registered: Nov 16, 2002
Posts: 1456
|
rrradam wrote: From what I understand: Everything still needs to travel through the pipes that come from our server.... In or out.
nope. If the image is hosted outside of the rc.com, the server sends only its address. Your browser takes the address of the image, and requests from the originating hosts. The image does not go through the rc.com server at all, if it is not hosted in rc.com domain.
|
|
|
|
|
rrrADAM
Dec 7, 2006, 9:05 AM
Post #11 of 23
(1989 views)
Shortcut
Registered: Dec 19, 1999
Posts: 17553
|
coldclimb wrote: It makes sense Adam, but I am reasonably assured that it's not the case. It COULD be the case if the site was designed that way... but why would it be designed to use more bandwidth? In general, unless built otherwise, your computer fetches the image from its host server, and rc.com simply says "It's over there ---->". The image does not go to rc.com, then to you, rc.com merelypoints you to it, your computer sends a request to that host and downloads the file, in addition to the stuff from the thread on rc.com, and your browser puts it all together and displays it. Someone correct me if I'm wrong, but I'm certain this is right.
OK... That makes sense too, and actually seems like a better way to do it.
Oh well... Good descriptive analogy, but not accurate regarding outside URLs.
Please ignore.
(This post was edited by rrradam on Dec 7, 2006, 9:07 AM)
|
|
|
|
|
atg200
Dec 7, 2006, 2:14 PM
Post #12 of 23
(1979 views)
Shortcut
Registered: Jul 27, 2001
Posts: 4317
|
Bandwidth has nothing to do with embedded images on outside sites, but it is of course a factor with images hosted on rockclimbing.com. So, threads like the women of rc.com thread would use a fair bit of bandwidth.
Some folks are wary of embedded images because of possible security/privacy concerns around cross site scripting exploits. A valid concern, but not one i lose sleep over.
I definitely think it is a real shame that the embedded images have gone away. Like it or not, the appeal of rc.com is 98% on the forums nd it is likely to stay that way. To me, removing embedded images has the effect of turning rc.com into a newspaper instead of a magazine.
|
|
|
|
|
phreezone
Dec 7, 2006, 3:40 PM
Post #13 of 23
(1967 views)
Shortcut
Registered: Sep 28, 2005
Posts: 5
|
I don't know if its the case here or not but at a few sites I work on takes the linked images, caches them on their servers and then resizes them locally then redisplays them to the user. This allows a few things.
First thing is that the images all are the same size physically or at least are not larger then X*X pixels as they appear inline. This is important if you want to eliminate the scroll bars that pop up on the bottom of a page if you link it to a raw digital photo on another webpage. If you link to a picture out of a 10+ megapixel camera you will only be seeing a portion of it before it scrolls off the page. This is the branding concept I've worked on elsewhere, making it look the same no matter what size photo gets linked. The resizing takes place using things like ImageMagick or similar software is installed on the server and set to run on each photo that is linked.
The second thing caching does is prevent the photos from being altered later. This is fairly common on sites like MySpace or porn sites where photo links get shared out. The original site admins will remove the original photos and replace them with pictures of things like warnings that the image was stolen from XX.com or even funnier is when they get replaced by photos of piles of shit or things that others will find gross. You may not realize the switch right away but looking in the archives later can prove enlightening since you'll now be linked to things you don't want to be.
Caching allows the uploader to be confident that their link will still be valid in the future if the 3rd party site would go offline for some reason or change their URL format string. Lots of photo sharing sites have came and gone in the last few years, there is no gaurente that PhotoBucket or what ever will still be around in a year, cacheing ensures as long as the fourm is online the photos will be valid.
All of this takes bandwidth since it needs to pull the photo from the referring website and store it in the local cache. Once its stored it then needs to be ran though the compression to rezise it (and usually store it as a different name while leaving the original untouched to still point to by clicking on the resized inline).
Issue that the site admins can face is they are now storing potentially copywritten photos that the users do not have the permission to use and that can place them in a difficult position if the copyright owner decides to sue. Thanks to the wording of copyright laws they are liable for a fine for each photo they broke the law on. A few hundred photos linked to by users could result in fines of $10000 or more plus legal fees... It would shut most non-industry websites down in a heartbeat to get hit with the lawsuit let alone try to fight it.
~A friendly DZ.com mod that would love to see inline photos at DZ.com also
(This post was edited by phreezone on Dec 7, 2006, 4:38 PM)
|
|
|
|
|
veganboyjosh
Dec 7, 2006, 4:08 PM
Post #14 of 23
(1965 views)
Shortcut
Registered: Dec 22, 2003
Posts: 1421
|
phreezone wrote: All of this takes bandwidth since it needs to pull the photo from the refering website and store it in the local cache. Once its stored it then needs to be ran though the compression to rezise it (and usually store it as a different name while leaving the original untouched to still point to by clicking on the resized inline).
and how does this bandwidth requirement compare to a video segment of x length, stored on the rc.com servers?
|
|
|
|
|
phreezone
Dec 7, 2006, 4:33 PM
Post #15 of 23
(1958 views)
Shortcut
Registered: Sep 28, 2005
Posts: 5
|
It depends, with a video the bandwidth is only used when the user uploads it and at each users download of the video. If 50 people view a 8 meg file thats 408 megs used. 400 down and 8 up.
Now if a user uploads 15 pictures at 1.5 megs each thats now 22.5 megs up. The server resizes them to say 250k each. That now puts 3.75 megs of photos in the thread. The thread is viewed a conservative 100 times. Thats 375 megs of data that is being sent. Take a thread that gets 400+ hits like most the Trip Report threads do, thats 1.5 gigis of data for one thread alone. Multiply that out across all the fourms and threads and it stands to use a LOT of bandwidth.
Granted photos could be scaled down to 100 k and it reduces the bandwidth but also reduces the quality.
|
|
|
|
|
atg200
Dec 7, 2006, 4:49 PM
Post #16 of 23
(1953 views)
Shortcut
Registered: Jul 27, 2001
Posts: 4317
|
yeah, 250K is awfully big for viewing a 640x480 on a web page - 100K should be more than plenty except for truly exceptional photos.
also worth noting is that very few hosting companies/colos bill by total bandwidth used - it is generally a percentile based on your heavy use periods, but throwing out exceptional bursts.
beyond that, trip report threads with a lot of photos in them are relatively rare - the more common use case is a thread with a handful of photos scattered around different pages of the thread.
also consider that of 400 views in a thread, probably more than half of them are people checking back into the thread to see updates, so they either miss the page with loads of photos or they have the images cached. an estimate of 1.5Gb for a thread like that is very excessive because it doesn't take any of these mitigating factors into consideration.
(This post was edited by atg200 on Dec 7, 2006, 4:50 PM)
|
|
|
|
|
zozo
Dec 7, 2006, 7:38 PM
Post #17 of 23
(1936 views)
Shortcut
Registered: Feb 3, 2004
Posts: 3431
|
It was a 99% rhetorical question as I do this for a living, but I just wanted to make sure before I asked why the owners would tell us it's a bandwidth issue when clearly it isnt.
And unless phreezone is correct in his scenario the bandwidth explanation is a crock. It seems it is just another way to maintain total content control.
I believe they are just worried about what people post and dont want to piss off or scare away advertising dollars - fine - just say that and dont assume that rank and file dont know what you know.
|
|
|
|
|
robbovius
Dec 7, 2006, 8:06 PM
Post #18 of 23
(1928 views)
Shortcut
Registered: Nov 20, 2002
Posts: 8406
|
climbsomething wrote: Adam's analogy makes sense to me, but I am of limited expertise myself. But who the hell still has dial-up?? .
I do. $22/month vs $50/mo. I pay $1200/mo in child support. which would you choose?
climbsomething wrote: Early official new-site language also indicated that embedded images would be eliminated because it was not a part of the new rc.com "brand." I don't believe that had anything to do with bandwidth, though what exactly the "brand" is to otherwise consist of, I dunno.
what it meant was "the new owners don't like embedded images, so we're gonna ditch it."
(This post was edited by robbovius on Dec 7, 2006, 8:09 PM)
|
|
|
|
|
climbsomething
Dec 7, 2006, 8:09 PM
Post #19 of 23
(1924 views)
Shortcut
Registered: May 30, 2002
Posts: 8588
|
robbovius wrote: climbsomething wrote: Adam's analogy makes sense to me, but I am of limited expertise myself. But who the hell still has dial-up?? . I do. $22/month vs $50/mo. I pay $1200/mo in child support. which would you choose?
|
|
|
|
|
climbsomething
Dec 7, 2006, 8:12 PM
Post #20 of 23
(1920 views)
Shortcut
Registered: May 30, 2002
Posts: 8588
|
Well, I knew a photo hosted offsite wouldn't affect rc.com bandwidth, but I still liked Adam's overall attempted analogy...
|
|
|
|
|
zozo
Dec 8, 2006, 4:30 PM
Post #22 of 23
(1866 views)
Shortcut
Registered: Feb 3, 2004
Posts: 3431
|
I would love to hear from ownership on this issue ...
|
|
|
|
|
stymingersfink
Dec 10, 2006, 1:41 AM
Post #23 of 23
(1831 views)
Shortcut
Registered: Aug 12, 2003
Posts: 7250
|
zozo wrote: I would love to hear from ownership on this issue ...
zozo? wrote: I would love to hear (a change of position) from ownership on this issue...
|
|
|
|
|
|
