Thread 'Why does core client use RPC for communication?'

Message boards : BOINC client : Why does core client use RPC for communication?
Message board moderation

To post messages, you must log in.

AuthorMessage
Twilyth

Send message
Joined: 15 Jun 07
Posts: 2
Message 10923 - Posted: 15 Jun 2007, 15:39:32 UTC

I use the Zone Alarm firewall and have been told that the core client uses RPC to communicate with the science applications. This apparently is the reason that ZA thinks that BOINC is constantly generating network traffic. Apparently, it is also the reason that the BOINC manager freezes when I block all internet activity using the ZA "Stop" button, but not when I simply disconnect the ethernet cable.

Is there any particular reason that BOINC uses RPC instead of a more conventional method of communication? Will future releases the problems this causes with Zone Alarm?
ID: 10923 · Report as offensive
ProfileJord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15585
Netherlands
Message 10928 - Posted: 15 Jun 2007, 21:11:34 UTC

What is a more conventional method to use when you try to run BOINC on one computer and track what it is doing with Boinc Manager on another computer? RPCs are very useful for that. What is even a more conventional method on a single machine? Big bulky programming, using lots of external APIs? Windows only?

But, since BOINC isn't using the internet for those connections, it's more of a ZA problem, isn't it? So work arounds are: Install BOINC as a service and only use the Manager when you need to check on it.

Although I read somewhere (can't remember where exactly) that you can set BOINC's parts in the exclusion zone in ZA these days. Then it won't register on ZA's system tray icon. I'm sure someone else can explain that.
ID: 10928 · Report as offensive
Twilyth

Send message
Joined: 15 Jun 07
Posts: 2
Message 10929 - Posted: 15 Jun 2007, 21:40:17 UTC - in response to Message 10928.  
Last modified: 15 Jun 2007, 21:41:35 UTC

What is a more conventional method to use when you try to run BOINC on one computer and track what it is doing with Boinc Manager on another computer? RPCs are very useful for that. What is even a more conventional method on a single machine? Big bulky programming, using lots of external APIs? Windows only?

But, since BOINC isn't using the internet for those connections, it's more of a ZA problem, isn't it? So work arounds are: Install BOINC as a service and only use the Manager when you need to check on it.

Although I read somewhere (can't remember where exactly) that you can set BOINC's parts in the exclusion zone in ZA these days. Then it won't register on ZA's system tray icon. I'm sure someone else can explain that.

What is with the attitude? I ask a simple question and get this bullsh*t. Have you been taking @sshole lessons from the CA's at WCG?

Not only that, you contradict yourself in the same post. First you say its used for communicating with boinc manager on ANOTHER computer, then you say it's ZA's problem since the comm is on the SAME computer? What's the matter? Split personality?

A more conventional method would be communicating via entries in a file or memory pointer - and viola - no bogus "net" traffic. ZA is just doing its job by preventing comm that LOOKS like it's local but may or may not be.

If you can't explain the reasoning for using this method, then feel free to go back to stuffing your head up you own . . .

See ya.
ID: 10929 · Report as offensive
Les Bayliss
Help desk expert

Send message
Joined: 25 Nov 05
Posts: 1654
Australia
Message 10930 - Posted: 15 Jun 2007, 22:04:36 UTC

In the Beginning, BOINC was a single program.
But lots of people had 'farms' of dozens of computers, and wanted an easy way to check up on all of them from a single computer, as some of their farm was in distant buildings.

And so, BOINC was split into 2 parts: The worker daemon, and the Manager, which is "just" a visual interface to show the user what the worker part is doing. And this new Manager has an option, ("Select computer"), to allow a user to connect this one Manager to the worker on many computers.
The worker on the local computer is called local host. It is the 'traffic' between the Manager and this local host that shows up your ZA. (And probably also when connected to a remote host.)

All of this has been written about before, both here and on the project sites. As has the advice to use the Exclude option in ZA to exempt BOINC from scrutiny.
And the same advice applies to ALL firewalls.

ID: 10930 · Report as offensive
ProfileJord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15585
Netherlands
Message 10931 - Posted: 15 Jun 2007, 22:05:59 UTC - in response to Message 10929.  

Not only that, you contradict yourself in the same post. First you say its used for communicating with boinc manager on ANOTHER computer, then you say it's ZA's problem since the comm is on the SAME computer? What's the matter? Split personality?

Now now... a bit less harsh please.

OK, BOINC communicates with BOINC Manager and the BOINC screen saver through RPCs. This is done on the same computer, but can also be done through the network, or indeed, through the internet. You can check a lot of computers with one BOINC Manager. This way you don't need to run to each computer if and when something goes wrong, you want to attach to a new project or detach from a certain project.
You can do it all from your own convenient chair.

A more conventional method would be communicating via entries in a file or memory pointer - and viola - no bogus "net" traffic.

That may be fine on one Operating System, but what of all the others out there?
BOINC is made with multiple OSes in mind. Using RPCs the developer can make one and the same routine for all those OSes, not having to write one for each OS separately.

Besides, a file means reading and writing from/to disk.
And the memory pointer.. well, what do you think an RPC is? :)
ID: 10931 · Report as offensive

Message boards : BOINC client : Why does core client use RPC for communication?

Copyright © 2025 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.