Non-Blocking mode setting in RPC

Non-Blocking mode setting in RPC

Post by Stuart Marqu » Wed, 10 Nov 1993 06:05:31




>Hi,

>   I wonder if there is a way to set the  Non-Blocking mode on sending/receiving
>in RPC without going down to the UNIX socket level, i.e. is there any
>way to set such Non-Blocking mode within a high-level RPC call.  I think
>that this is something that RPC library should provide.

>   Your help and time is greatly appreciated.

Did anyone answer this yet?
I have to do this for a project here, too.  The only way I can think of
is kind of messy:

In the Sun Network Programming manual, it has a section entitled "Select
on the Server Side" - it tells how the _server_ can run asynchonously,
by hand-coding a select() against the rpc-related sockets, then calling
svc_getrequest() when something comes in.  The select() can have a timeoout
associated with it, and that's where you get your asynchronicity.

This doesn't go quite all the way down to sockets, but it go down
further than would be hoped.

If you want the _client_ to run asynchronously, then you can use what
Sun calls "Batching" - The client sends a request to the server, but
the server-side rpc is written so that it returns an ACK immediatly,
then does the processing.  The client recieves the ACK, then does
whatever it wants for a while.  Later, the client sets himself up as
an rpc-server, and the server process calls the client with the
results of his work.  Also messy, but explained in most rpc network
programming guides.

But I don't really like these techniques, because I find them pretty
confusing, and writting code this way gets involved in too many low-
level things - And the point of rpc's is to avoid all this complexity.

Does anyone know of a simpler way so use rpc's asynchronously?

Quote:

>Best Regards,

>--Junwen

--
--   Stuart Marquis                --   It's simple.  If I said it,        --

"Their eyes meet and her heart starts flopping around weakly, like a bunny
in a Ziploc bag.  He grins and waves." - Stephenson, Snow Crash
 
 
 

Non-Blocking mode setting in RPC

Post by My Us » Thu, 11 Nov 1993 13:16:08



: >Hi,
: >
: >   I wonder if there is a way to set the  Non-Blocking mode on sending/receiving
: >in RPC without going down to the UNIX socket level, i.e. is there any
: >way to set such Non-Blocking mode within a high-level RPC call.  I think
: >that this is something that RPC library should provide.
: >
: >   Your help and time is greatly appreciated.

: Did anyone answer this yet?
: I have to do this for a project here, too.  The only way I can think of
: is kind of messy:

: In the Sun Network Programming manual, it has a section entitled "Select
: on the Server Side" - it tells how the _server_ can run asynchonously,
: by hand-coding a select() against the rpc-related sockets, then calling
: svc_getrequest() when something comes in.  The select() can have a timeoout
: associated with it, and that's where you get your asynchronicity.

: This doesn't go quite all the way down to sockets, but it go down
: further than would be hoped.

: If you want the _client_ to run asynchronously, then you can use what
: Sun calls "Batching" - The client sends a request to the server, but
: the server-side rpc is written so that it returns an ACK immediatly,
: then does the processing.  The client recieves the ACK, then does
: whatever it wants for a while.  Later, the client sets himself up as
: an rpc-server, and the server process calls the client with the
: results of his work.  Also messy, but explained in most rpc network
: programming guides.

: But I don't really like these techniques, because I find them pretty
: confusing, and writting code this way gets involved in too many low-
: level things - And the point of rpc's is to avoid all this complexity.

: Does anyone know of a simpler way so use rpc's asynchronously?

: >
: >Best Regards,
: >
: >--Junwen

If you think about this for a second, you will see why it has to be one of
these two choices.  The RPC model is, after all, a synchronous creature:
make a call, get a response.  In order to do async replies, RPC would have
to svae a lot of state (meaning static or dynamic rather than automatic
storage) and do something even uglier (like set an interval timer).  This
could create all kinds of problems.  The best solutions (IMHO) are either
to write a threaded application so you needn't worry about blockage or
to use one-way RPC's followed by FRPC's for the replies.  This allows you
to do watch whatever else you need to watch.  Note that if your client is
a purely temporary beast, the FRPC is kind of a pain.

I'm not sure, however, what the exact problem is that you are trying to
solve.  The usual reason for resorting to asycn RPC is because your
server has to service some non-RPC function (like a data feed).  If all
you are doing is one RPC service, would you actually be able to do anything
useful for client b if client a's request isn't complete yet?

                                Dave

: --
: --   Stuart Marquis                --   It's simple.  If I said it,        --

: "Their eyes meet and her heart starts flopping around weakly, like a bunny
: in a Ziploc bag.  He grins and waves." - Stephenson, Snow Crash

 
 
 

Non-Blocking mode setting in RPC

Post by Martin Janz » Sat, 13 Nov 1993 08:03:06



>[...]
>In the Sun Network Programming manual, it has a section entitled "Select
>on the Server Side" - it tells how the _server_ can run asynchonously,
>by hand-coding a select() against the rpc-related sockets, then calling
>svc_getrequest() when something comes in.  The select() can have a timeoout
>associated with it, and that's where you get your asynchronicity. [...]

>If you want the _client_ to run asynchronously, then you can use what
>Sun calls "Batching" - The client sends a request to the server, but
>the server-side rpc is written so that it returns an ACK immediatly,
>then does the processing.  The client recieves the ACK, then does
>whatever it wants for a while.  Later, the client sets himself up as
>an rpc-server, and the server process calls the client with the
>results of his work.  Also messy, but explained in most rpc network
>programming guides.

That's one way to do it.  Actually, it's not necessary for the server to
return an ACK immediately; the section on "Batching" describes how to
send a request in such a way that RPC doesn't expect a response at all.
(Their example shows how this can improve performance when transferring
a lot of data in one direction, by eliminating round-trips and allowing
requests to be buffered.)  In this case, the client must eventually send
a non-batched request, to flush the XDR buffers.

Alternatively, the client can call

  timeout.tv_sec = timeout.tv_usec = 0L;
  clnt_call(handle, proc_num, arg_xdr_proc, &arg, xdr_void, NULL, timeout);

The combination of the xdr_void procedure and the zero timeout causes
the request to be sent immediately, without waiting for a response.
If successful, clnt_call returns RPC_TIMEDOUT instead of RPC_SUCCESS.

Quote:>But I don't really like these techniques, because I find them pretty
>confusing, and writting code this way gets involved in too many low-
>level things - And the point of rpc's is to avoid all this complexity.

>Does anyone know of a simpler way so use rpc's asynchronously?

No, not with Sun's ONC RPC 4.0, anyway.  Your best bet is to write a set
of wrapper functions which hide the*details.

--

Pegasus Systems Group   c/o Hewlett-Packard, Idacom Telecomm. Operation

 
 
 

1. How to set non-blocking mode on a stream

I'm working on a user level module that's communicating with a
driver via streams.  I can't figure out how to put it in non-
blocking mode.  I'm using the "NCR System 3000 UNIX SVR4 MP
Programmer's Guide: STREAMS" as a reference.  The only mention of
non-blocking that I could find in the book was in the discussion of
the M_SETOPTS message.  It reads as follows:

     M_SETOPTS

     Used to alter some characteristics of the Stream head.
     It is generated by any downstream module, and is
     interpreted by the Stream head.  ...

I take this to mean that can't be sent from the user level.  Can
non-blocking be sent from the user level?  If yes, how is it done?
If no, how do programmers typically get around this problem?

Thanks for the help,
Dick

Dick Libby                          Phone:   (612)-638-7255

Network Products Division
2700 Snelling Ave N.
St. Paul, MN 55113

2. public newsserver that allows posting to this group

3. How do I set a non-blocking socket back to blocking?

4. linux on small notebook (486sx/4mb)

5. Non-blocking RPC

6. Is There A Way to Modify ISO Image Files?

7. Semantics of non-blocking "passive"-mode SOCK_STREAM sockets

8. Help Kernel Upgrade

9. How to check connection loss in non-blocking mode

10. "Raw" and "Non-blocking" terminal mode in Linux

11. Executing a command in "non-blocking" mode?

12. "unable to set non-blocking on pty"

13. How do I set a socket to non-blocking?