|
||||
|
Interesting question. IMHO, they're already a threat, especially to small web site operators who graciously post images that get "borrowed" without permission (read stolen).
I'm thinking in particular of how some of the 5.0 versions of Yahoo Messenger allow some HTML, including images. People point to images served off of someone else's web site, consuming bandwidth (which can be expensive) and slowing down their web site for no real gain. Of course, when people start going nuts with that, the problem grows exponentially, to the point where all of us are effected because of the increased traffic flowing throught the 'net. I think some basic formatting is a good thing, but the rich media stuff has got to have it's limits! fanatic has spoken! <img src=icon_smile_big.gif border=0 align=middle> fanatic |
|
||||
|
Good points, fanatic. Frankly I don't see that as a threat to the net so much as a threat to the small-scale web site operators trying to keep things lean-and-mean.
As for choking net traffic, seems like audio and video have the most potential for sucking up bandwidth. Most of the IM products have audio now, and some have video capability. As this catches on, will this mean slower internet speeds for all of us? Jeff Hester BigBlueBall.com |
|
|||
|
I accept that pics are stolen, also MP3's, however thats not the point here, pics and text files are quite small. Rarely do they reach the size of MP3's at from 3meg and upwards.
Now that AOL have thrown AIM into the music transfer pool my fears are not for a reduced speed of the web, more for a reduced capacity and speed for chat. The channel used by chat was never expected to carry such massive traffic. Why not 'horses for courses' ? let chat remain for chat and provide another medium for massive file transfers. Edited by - rustedtight on 01/27/2002 11:08:27 |
|
||||
|
Rustedtight, you raise an interesting concept in "channels." Although in reality we may not be able to provide that distinction over the Internet backbone. Its the cumulative total of traffic that causes concern.
Another way to look at it is like this: Think of internet traffic like water flowing through a pipe. Now unfortunately we don't have separate pipes for chat, email, web browsing, video and so forth. It's all just one, big pipe. When there's a lot of activity, the pipe fills up. There are some tricks to pump data faster, but their are very real limits to how much you can push through a given "pipe." The only options are to reduce the volume of traffic, expand the capacity (more or bigger "pipes"), or invent new technology that lets you route more data, faster. Note that your own experience of the Internet is also effected by the speed of your connection. In fact, that's usually the single most important factor effecting your Internet speed. You could think of dial-up as tapping into that big pipeline with a straw. <img src=icon_smile_wink.gif border=0 align=middle> Jeff Hester BigBlueBall.com |
|
|||
|
<img src=icon_smile_shy.gif border=0 align=middle>OK,
Lets dispense with the channel concept and look at the big pipe, the flow supplied as it is by tens of thousands of servers. I will use non technical terms mainly cos I aint technical, and others can follow my logic (or lack thereof). Now most messages/chat transmissions being text, I guess would be each well under 2k, pics are around 70k average, MP3's are around 4meg, and dvd's? the sky is the limit. OK, servers handling chat have an average sender bundle of say 8k, no drama there. within the flow stream then every 8k is a new 'bundle', (my 'straw' can well handle that) I can wait........ my next 'bundle' is not far away. Cool, however, now throw in MP3's and the server load shifts from 8X all the way up to and possibly exceeding 3000X, a massive increase in traffic thru a server (correct me if I'm wrong but isnt that how a DoS attack brings down a server?). Now my wait (with my adequate straw) is increased as the 'bundles' are further apart? all by a factor of (3000 divided by 8) 375. A sizeable 'wait' in any language. This description is flawed in as much as theres no 'bundle' of data sent, more correctly they are 'packets' much smaller, however you must collect all your 'packets' before you can assemble your 'bundle' (message). That being the case, surely this massive increase thru a finite number of chat servers must slow the general chat thru traffic by a not insignificant amount. The all over effect on the web is insignificant I agree. I accept the lack of capacity n flow thru my straw, I'm still waiting 375 times longer to see my senders message and so is everybody else. Now is where I bring back the 'channel' concept and shift the traffic off the chat channel and onto a dedicated 'music' channel, now my wait is back at the 8X level. All I suggest is not including MP3's and large files within the chat traffic dedicated servers. I am a user of peer to peer file swapping and as such can see that the more popular a service is, the slower it is, the unique and little known services are certainly faster. so with this understanding I have applied it to chat with MP3's possibly included. Hey! its female logic, OK. Afterall, when a DoS attack hits say Sun micro or IBM or God forbid, Microsoft, my concept of the traffic thru the pipe is that nothing much has happened. |
|
||||
|
You bring up some good points, but I think your concept of "channels" (different servers for different data) is already the norm. Don't think that just because you're sending voice, or video or sharing files or whatever through your instant messenger that it's going through a "chat server."
Let me clarify a few points: Quote:
" that takes only about 34 bytes. So you are correct that the packets are very small. However... The two biggest instant messengers (AOL Instant Messenger and MSN Messenger) do not use central chat servers to route instant messages at all! The central server is nothing more than a member directory that maintains online status and makes it possible for members to connect. So once I've established an instant messaging session with you, our "packets" are going from my PC to yours (not through a chat server). This is true whether I'm using text, file transfer, voice or video. Now that is not true for all messengers. ICQ, Yahoo and Odigo all route messages through a chat server (that's how they provide "offline" message capabilities). But even with those, when you establish a voice connection, for instance, the voice data does not go through a server. So here is a picture of what I'm describing: With MSN and AIM: ![]() Here you can see my message goes through my Internet connection (which might be slow), to the Internet (which is usually pretty fast), and finally to your connection (which again might be slow). The "big pipe" of the Internet is also carrying other data (web pages, file transfers, email, streaming media and so forth). With ICQ, Yahoo and Odigo: ![]() Here my messages travels through my connection to the Internet, through the Internet to a server (more likely one of many servers), back through the Internet to your connection. You can see how this increases to potential bottlenecks (the server could become overloaded, the connection to the server might be flooded with message traffic, etc.). So what are the potential bottlenecks?
The point being that the "pipe" between two points, whether those two points are user-to-user or user-to-server, is going to fill up. It's really not an instant messaging problem, per se, but the concern is that because of the ubiquitous nature of instant messaging, adding rich media to IM will cause network congestion much faster than any other medium (web sites, net radio, etc.). Of course, adding to this mess is the fact that more and more people are getting broadband (fast access) at home, making it feasible for them to download HUGE files which they previously would never have attempted. What's the bottom line? Well, the "pipe" is filling up anyway, regardless of what happens with IM and rich media. The debate is whether it will fill up faster if IM becomes laden with multimedia. And the answer is..... Jeff Hester BigBlueBall.com |
![]() |
| Currently Active Users Viewing This Topic: 1 (0 members and 1 guests) | |
| Topic Tools | |
|
|
Similar Topics
|
||||
| Topic | Topic Starter | Forum | Replies | Last Post |
| A.I.M FRAME | SCPGIRL39 | AIM Support | 4 | 11-02-2005 10:08 AM |
| Mobile Instant Messaging with Instant Multimedia Audio/Video | BigBlueBall News | General / Other IM News | 0 | 11-21-2004 01:00 AM |
| Canadians embrace instant messages | BigBlueBall News | AIM News | 0 | 11-25-2003 01:00 AM |
| IM Threat to Net? | BigBlueBall News | General / Other IM News | 0 | 01-14-2002 01:00 AM |
| Instant Messaging Has Gone to Work | BigBlueBall News | General / Other IM News | 0 | 11-20-2001 01:00 AM |