G.Eustace@massey.ac.nz (Glen Eustace) (11/19/90)
I am just starting to write some programs that use RPCs but have hit a problem. I admit to being a complete novice in this area. I have RTFMs but still am not sure where I am going wrong. It could well be that I simple don't understand what I am reading. I would be very appreciative of someone pointing me at the error in my ways or sending a fragment of code that achieves the correct result. All the examples of RPC servers that I have seen seem to rely on the client calls being able to be executed rapidly. Hence all client calls can and are serviced by a single daemon e.g. mountd, quotad etc etc. What I was hoping to do was the following; Client side. ============ clntudp_create(); ... clnt_call(); /* rpc procedure 1 */ ... clnt_call(); /* rpc procedure 2 */ ... clnt_call(); /* rpc procedure 3 */ ... clnt_destroy(); some of the rpc procedures may take a non-trivial length of time. What I thought was the correct thing to do, on the server side, was to create a new instance of the daemon when the clntudp_create is executed and let that client/server pair talk to each other until the clnt_destroy at which time the server terminates. My thinking was that additional client/server pairs would be created as needed. I can't seem to work out how one can actually do the above. By implication I am wondering if this is the correct way to do things. If it is, how does one handle the new client/server pairs in the server code? If it is not the correct way to do things how does one prevent a new client from having to wait for an earlier one to complete its processing? My line of thought was based on the TCP idea i.e. telnet, where a connection is made on a well known port and then the server and client shift their conversation to another thus making the well known port available for a new connection. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen Eustace, Software Manager, Computer Centre, Massey University, Palmerston North, New Zealand. EMail: G.Eustace@massey.ac.nz Phone: +64 63 69099 x7440, Fax: +64 63 505 607, Timezone: GMT-12
vipin@eng.sun.com (Vipin Samar) (11/20/90)
G.Eustace@massey.ac.nz (Glen Eustace) writes: >What I thought was the correct thing to do, on the server side, was >to create a new instance of the daemon when the clntudp_create is >executed and let that client/server pair talk to each other until the >clnt_destroy at which time the server terminates. My thinking was >that additional client/server pairs would be created as needed. >I can't seem to work out how one can actually do the above. As far as the client is concerned, it should not care whether a new instance is created or whether the same old server can serve your request. The server created through svcudp_create() [or done via rpcgen] answers your requests itself. It treats each request as an independent one. However, if you were to use TCP [svctcp_create()], the server creates a connection [in the same process] and then the client and the server can merrily go along exchanging messages. When the client dies [clnt_destroy], the server is notified and it cleans up. You, as a programmer, need not do anything special on either ends. Does this help? >If it is not the correct way to do things how does one >prevent a new client from having to wait for an earlier one to >complete its processing? The current implementations are single threaded - so while a particular request is being served, the server will not entertain other requests. However, one can interleave requests from other clients. In the case of TCP, even though different connections have been set up with different clients, their requests are still serialized. >My line of thought was based on the TCP >idea i.e. telnet, where a connection is made on a well known port and >then the server and client shift their conversation to another thus >making the well known port available for a new connection. In case of ftp, telnet, etc., the server forks for every new request and this is different from vanilla ONC-RPC implementation. One can however, put in enough smarts into svc_tcp.c code to achieve the above. You should be able to get hold of all the source code - the code is freely licensable. >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Glen Eustace, Software Manager, Computer Centre, Massey University, vipin Disclaimer: I speak for no one but myself. -- vipin@Eng.sun.com || sun!Eng!vipin