next up previous contents
Next: Implementation Up: A talk program Previous: A talk program

Design of the interface

A true talk program must have some daemon to notify a user that someone else is trying to initiate talk with him/her. We can certainly write such as server using powerRPC, however, this is not the purpose of this demo, since you can already write such a server after learning the powerRPC from the material above.

Our talk system will be just one program named talk2. One user starts talk2 first, and another user executes the same program to communicate with the first user, knowing he/she is there waiting. Talk2 must be both a server and a client of the same RPC interface, when sending message to the peer, it is a client, when receiving message, the role is reversed, and it becomes the server.

What we are going to do requires more from both powerRPC and the programmer.

The talk RPC interface contains a single function: send_msg().

interface talk2 {

  property   TRANSPORT_PROTOCOL = udp;
  property   GEN_MAIN_FUNC = false;
  property   SERV_CALL_PREFIX = s_;

  void  send_msg(
        unsigned long sender_program_no,
        char [size = strlen(sender_host) + 1, 1024] sender_host,
        char [size = strlen(sender_name) + 1, 1024] sender_name,
        char [size = strlen(msg) + 1, 4096] msg
  ) = 1;

} = 0x9999;

The send_msg() RPC takes four arguments, the first three identifies the sender, the last one is the message being sent. Since talk2 is both a server and a client, we must define the property SERV_CALL_PREFIX, so the server implementation of the send_msg is actually named s_send_msg. We also need to write our main() function, therefore the GEN_MAIN_FUNC property is set to false.



Copyright (C) Netbula LLC, 1996