|
Home > Archive > Unix Programming > August 2006 > Use RPC?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| moleskyca1@yahoo.com 2006-08-16, 1:25 pm |
| Should I use RPC or just code my own UDP server that can do work sent
from client in a message?
I wonder about the overhead of using RPC and what is the faster way?
When should you use RPC and when should you write your own server that
can wait for message, do work and send back to client results in
another message?
Any guidelines?
| |
| Barry Margolin 2006-08-17, 1:28 am |
| In article <1155736541.845083.278100@m73g2000cwd.googlegroups.com>,
moleskyca1@yahoo.com wrote:
> Should I use RPC or just code my own UDP server that can do work sent
> from client in a message?
>
> I wonder about the overhead of using RPC and what is the faster way?
>
> When should you use RPC and when should you write your own server that
> can wait for message, do work and send back to client results in
> another message?
That's pretty much all that RPC does. It also takes care of marshalling
the data and results, which a non-RPC client/server would usually have
to do itself.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Chuck Dillon 2006-08-17, 1:19 pm |
| moleskyca1@yahoo.com wrote:
> Should I use RPC or just code my own UDP server that can do work sent
> from client in a message?
There are lots of RPCs I assume you are referring to the standard RPC
available on *NIX.
If you plan to support clients running in the non-*NIX world (e.g.
Winders) be aware that there are two RPC standards and MicroSoft
doesn't use the same one as *NIX. That doesn't mean RPC is the wrong
way to go it just means be aware of the hidden costs of supporting
cross-platform with RPC.
If your protocol involves up/downloading or streaming large volumes of
data you're probably going to end up with a separate connection to
support that. If that is most of what you are doing then RPC may not
be the right choice.
-- ced
>
> I wonder about the overhead of using RPC and what is the faster way?
>
> When should you use RPC and when should you write your own server that
> can wait for message, do work and send back to client results in
> another message?
>
> Any guidelines?
>
--
Chuck Dillon
Manager of Software Development, Bioinformatics
NimbleGen Systems Inc.
|
|
|
|
|