包子答谢--请教高手：streaming data to applet - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Java - 爪哇娇娃

包子答谢--请教高手：streaming data to applet

包子答谢--请教高手：streaming data to applet# Java - 爪哇娇娃

F*e2008-11-13 08:11

1 楼

on the client side, I have an applet which gets data from backend/server
side.
The data on the server keeps changing. What is the best way to get up-to-
date data on the applet side?
Options I see: polling, RMI, JMS, other options?
什么办法最efficient而且又不难做？先谢了。

g*g2008-11-13 08:11

2 楼

If it doesn't have to be very real time, then polling would be simplest.
You can't open a server socket on applet anyway and your option is limited.

【在 F**e 的大作中提到】

: on the client side, I have an applet which gets data from backend/server
: side.
: The data on the server keeps changing. What is the best way to get up-to-
: date data on the applet side?
: Options I see: polling, RMI, JMS, other options?
: 什么办法最efficient而且又不难做？先谢了。

F*e2008-11-13 08:11

3 楼

thanks.
if I do want as real time as possible, what would be your next choice,
balancing efficiency/speed/ease of
implementation?

【在 g*****g 的大作中提到】

: If it doesn't have to be very real time, then polling would be simplest.
: You can't open a server socket on applet anyway and your option is limited.

g*g2008-11-13 08:11

4 楼

Using RMI may be possible achieve near real time, but if the end user
is inside firewall, it becomes big problem. For me, the best approach
may be polling to check status (not data) very frequently, and get data
whenever status is changed.

【在 F**e 的大作中提到】

: thanks.
: if I do want as real time as possible, what would be your next choice,
: balancing efficiency/speed/ease of
: implementation?

c*t2008-11-13 08:11

5 楼

This is assuming data is big. If the data is small, then it basically
can be transmitted in a single packet or two in some cases. The minimum
size of packet is actually quite big, usually 1k size.

【在 g*****g 的大作中提到】

: Using RMI may be possible achieve near real time, but if the end user
: is inside firewall, it becomes big problem. For me, the best approach
: may be polling to check status (not data) very frequently, and get data
: whenever status is changed.

F*e2008-11-13 08:11

6 楼

so you are saying best to use RMI?

【在 c*****t 的大作中提到】

: This is assuming data is big. If the data is small, then it basically
: can be transmitted in a single packet or two in some cases. The minimum
: size of packet is actually quite big, usually 1k size.

c*t2008-11-13 08:11

7 楼

RMI doesn't really help. RMI is simply a protocol of transfering objects
on top of TCP/IP.
Honestly, I think that you should research this problem yourself and
do some readings. Also, you need to consider the number of clients,
the number of simultaneous requests, the size of the returned data,
the time it takes to compute/retrieve the data, and the definition
of "real-time". Some real-time maybe 15-sec refresh or manual refresh.
Consider these and you won't be too clueless.
Usually polling i

【在 F**e 的大作中提到】

: so you are saying best to use RMI?

F*e2008-11-13 08:11

8 楼

Thanks for your suggestions. I'll definitely start with polling.

【在 c*****t 的大作中提到】

: RMI doesn't really help. RMI is simply a protocol of transfering objects
: on top of TCP/IP.
: Honestly, I think that you should research this problem yourself and
: do some readings. Also, you need to consider the number of clients,
: the number of simultaneous requests, the size of the returned data,
: the time it takes to compute/retrieve the data, and the definition
: of "real-time". Some real-time maybe 15-sec refresh or manual refresh.
: Consider these and you won't be too clueless.
: Usually polling i

F*e2008-11-13 08:11

9 楼

Eventually I need subsecond latency and there could be many concurrent
request. What will be my
best choice?

【在 c*****t 的大作中提到】

c*t2008-11-13 08:11

10 楼

You didn't provide information on the size of the data, the frequency
of the update, the processing time of the data, and why you would need
have such frequent update etc.
If you envision the update will be very frequent, much like playing an
interactive game, then you will need to keep a live connection. That's
for sure since the TCP/IP overhead is significant. You will also have
to get someone who is really experienced to work on it, to design the
whole architecture. It is not going to be t

【在 F**e 的大作中提到】

: Eventually I need subsecond latency and there could be many concurrent
: request. What will be my
: best choice?