This week's book giveaway is in the JavaScript forum.
We're giving away four copies of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js and have Paul Jensen on-line!
See this thread for details.
Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Communication between server and clients.  RSS feed

 
Qunfeng Wang
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From the projects I worked on, there are two architectures mainly used.

1. Synchronize: Clients always wait until getting data from server. When setting data, clients will block until the server method invocation returns. It can ensure you always get the latest data from the server. But it will increase your data flow from server and clients. And it will also increase GUI's response time.

2. Asynchronous: Clients maintain a cache, which is updated by the server with notifications. When getting data, clients get data directly from the cache, which will decrease the data flow and GUI's response time. Given the situation that the notifications may take a while to go, the clients may not get the latest data. When comes to multiple clients, it can get worse, a client can override another client's modification without known.

Are there any better choice? Which one do you use in your application, and why do you choose that one?

Thanks.
 
Rob Spoor
Sheriff
Posts: 21044
85
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd go for event base triggering:

In a separate thread the clients handle all the communication with the server. When you read some data you update your user interface immediately using EventQueue.invokeLater or EventQueue.invokeAndWait.

Another possibility is using SwingWorker, especially if all the data is of the same format. You override doInBackground to do the listening part. Then when you read data you publish() it. You also override process to do the interaction with the user interface. Then when you're finished you can override done to do some finalization in the user interface.

In pseudo code:
 
G Estes
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It would all depend on what the requirements dictate. By that I don't mean the end user wants Synch or Asynch, but what the design solution needs to do its job. If there is a requirement for the client to process a list of Orders one at a time, and only to move to the next when the first is complete...then Synch. If the client is allowed to fire off Orders and not care at the time what happens (i.e. another streamer thread handles failures, etc...) then Asynch.

The question you should ask is: For set of behaviours ABC, what is the better implementation?

Just my 2 cents worth...
 
Rob Spoor
Sheriff
Posts: 21044
85
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should use a different thread altogether, because otherwise the entire GUI will freeze. That's not only no new events, but also no repainting. And that's definitely not what you want.

What I usually do in these cases is disable all controls that shouldn't be allowed, then start the thread, and once that's finished enable the controls again.

That or show a dialog with a progress bar.
 
G Estes
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
True, I presumed a thread would be used for processing the request...how the UI handles it (progress bar, etc...) is a design consideration.

Cheers!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!