aspose file tools*
The moose likes Java Micro Edition and the fly likes how can I know bandwidth Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Mobile » Java Micro Edition
Bookmark "how can I know bandwidth" Watch "how can I know bandwidth" New topic
Author

how can I know bandwidth

ying qu
Greenhorn

Joined: Jun 20, 2002
Posts: 13
Hi:
I'm implementing a midlet under J2ME Wireless Toolkit. I want to know how many bit/second the current network-connection bandwidth is in my application, how can I get this data with Java? Is there anybody know the answer?
Thanks a lot!!
Ying


ying qu
Michael Yuan
author
Ranch Hand

Joined: Mar 07, 2002
Posts: 1427
I guess I have to ask, why do you want to know this? The wireless toolkit uses your host PC's internet connection. The network performance on real devices could be very different. I do not see how that information can be useful.
If you really really want to do it, you can just download a large file using your MIDlet and use a MIDP Timer object to time it ...


Seam Framework: http://www.amazon.com/exec/obidos/ASIN/0137129394/mobileenterpr-20/
Ringful: http://www.ringful.com/
Rishi Tyagi
Ranch Hand

Joined: Feb 14, 2002
Posts: 100
Michael Yuan,
I agree with you that in general we don't need this.
But if we want to download some fix amount of data and want to tell the user that how much time it will take to download data and also wnat to show the progress on the screen in this case we may need the same.
I would also like to know if there is any method available in j2men for the above and will be highly obliged if anybody can help on the same.
Regards,
Rishi
Sayed Ibrahim Hashimi
Ranch Hand

Joined: May 17, 2001
Posts: 148
I don't know your answer but, you might have to specify wether you want to know the max bandwidth (ie 100mb/s) or at what rate a file is downloading because those are two different questions.


SCJP 1.4<br /><a href="http://www.cise.ufl.edu/~sih" target="_blank" rel="nofollow">www.cise.ufl.edu/~sih</a>
Michael Yuan
author
Ranch Hand

Joined: Mar 07, 2002
Posts: 1427
Originally posted by Rishi Tyagi:
Michael Yuan,
I agree with you that in general we don't need this.
But if we want to download some fix amount of data and want to tell the user that how much time it will take to download data and also wnat to show the progress on the screen in this case we may need the same.

Well, no method can reliabllly predict the download time. The connection might be dropped the next second.
If you want to show a progress bar and give educated guess on how long the remaining of the doanload should take, you can just do what we always do in the J2SE world:
Get the total size from the HTTP header;
Keep record on how much data has been read;
Show the percentage bar;
Keep record on how much time has lapsed;
calculate the estimated remaining time.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Michael Yuan:
I guess I have to ask, why do you want to know this? The wireless toolkit uses your host PC's internet connection. The network performance on real devices could be very different. I do not see how that information can be useful.

Because it may effect what choices the user makes. At the microscopic level, there's the estimated download time ("hmm... I don't really want to wait 10 minutes to download this app, I'll do it when I get home"). At the macroscopic level, the user may engage in a task which requires heavy bandwidth use, or may choose to hold off on starting that task until another time.
My experience has suggested that bandwidth is often the most constrained resource on wireless devices. Memory and speed, while limited, are fixed. Bandwidth is limited, and occasionally even more so, and sometimes altogether gone.
--Mark
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
If you wanted to "guesstimate" the time remaining (knowing full well that the guesstimate will change constantly), couldn't you...
While you are looping periodically take note of the time and the amount of data downloaded. By comparing the times and amounts you should be able to get a throughput value (...some amount of data per some amount of time), that can be divided into the remaining data to get an estimate based upon the last "time periods" thoroughput.
Obviously, this could bounce around alot so you might want to use multiple time periods to reduce volatility. It might be simple average or one which weights more recent timings higher than others.
Regards,


Byron Estes<br />Sun Certified Enterprise Architect<br />Senior Consulant<br />Blackwell Consulting Services<br />Chicago, IL<br /><a href="http://www.bcsinc.com" target="_blank" rel="nofollow">www.bcsinc.com</a>
Michael Yuan
author
Ranch Hand

Joined: Mar 07, 2002
Posts: 1427
Originally posted by Mark Herschberg:

My experience has suggested that bandwidth is often the most constrained resource on wireless devices. Memory and speed, while limited, are fixed. Bandwidth is limited, and occasionally even more so, and sometimes altogether gone.

Hi Mark,
If bandwidth is so unstable and can be "altogether gone", it makes even less sense to predict download time based on historical data. Right?
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Michael Yuan:

If bandwidth is so unstable and can be "altogether gone", it makes even less sense to predict download time based on historical data. Right?

Obviously you can't always know when a network will necessarily go down, or when your train might go through a tunnel. However, the network is more unstable over "long" periods, but relatively stable over "short" periods. By this I mean, if you are downloading a file at a certain rate, it's unlikely in the next 20 seconds the rate will differ much.
On the other hand, physical location (strong or weak signal, building in the way), weather, and network load vary both during the day and from day to day.
--Mark
Stefan Haustein
Author
Greenhorn

Joined: Jul 28, 2002
Posts: 9
Well, some kind of progress bar would at least help the user to determine whether the application is still downloading or already crashed, even if it is not very reliable. However, for this purpose it is probably necessary that the download takes place in a separate thread, otherwise it may block the display: Some devices do not show screen updates until the command handler returns.... (and according to the MIDP spec the commandAction() method should return immediately)
Best,
Stefan


Stefan Haustein <br />Co-Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/0672320959/ref=ase_electricporkchop" target="_blank" rel="nofollow">Java 2 Micro Edition Application Development</a>"
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: how can I know bandwidth