F**e
发帖数: 593 | 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*****g
发帖数: 34805 | 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**e
发帖数: 593 | 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*****g
发帖数: 34805 | 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*****t
发帖数: 1879 | 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**e
发帖数: 593 | 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*****t
发帖数: 1879 | 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**e
发帖数: 593 | 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**e
发帖数: 593 | 9 Eventually I need subsecond latency and there could be many concurrent
request. What will be my
best choice?
【在 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
| c*****t
发帖数: 1879 | 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?
| c********g
发帖数: 449 | 11 how about applet<--------------->servlet. |
|
