This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RPC clnt_create() adress already in use

Hello Raimund,
Let's keep this on the mailing list please.

PAULUS, Raimund, TI-ABN wrote:
Hallo Mark Geisert,

many thanks for your answer. I supposed this too.

I included in my source code the following function calls after clnt_create():

int fd = 0;
bool bool_ret = clnt_control(cl, CLGET_FD, &fd); if(bool_ret == true) {
  printf("fd: %d\n", fd);

  int enable = 1;
  retval = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &enable, sizeof(int));
  if(retval < 0)
    fprintf(stderr, "Fehler setsockopt(): %s\n", strerror(errno)); }

The function clnt_control() delivers the socket of the RPC-Client-Handle.
The result is the same as before. Moreover i think, the effect of setsockopt() would be valid only during the process is running (my test scenarios 1 and 2).
But it wouldn't change anything regarding my test scenario 3 (several restarts).


I looked through the libtirpc source code and nowhere is SO_REUSEADDR being set. You are on the right track with how to do it, but by the time clnt_create() returns to you it is already too late. As far as I can tell there is no way to get access to the socket between the time it's created within libtirpc and the time it's made available to you by clnt_create().

I did try running your testcase (thanks for supplying that) but I don't have a local machine running RPC services and don't wish to poke at random machines on the Internet ;-). I had to compile it as so:
    gcc -g -o test_rpc -I/usr/include/tirpc test_rpc.c -ltirpc
You are taking care to compile against the correct RPC-package includes and link against the correct RPC-package libraries, yes?

Speculation: There might be a way to decompose what clnt_create() does into other libtirpc functions that accomplish the same thing, but in smaller pieces such that you could set the socket option before bind() is called. That would be a fair amount of work though and given my cursory look at the source I don't know if it's even possible.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]