[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference tuxedo::dce-products

Title:	DCE Product Information
Notice:	Kit Info - See 2.-4.
Moderator:	TUXEDO::MAZZAFERRO

Created:	Fri Jun 26 1992
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2269
Total number of notes:	10003

2217.0. "rpc__naf_desc_inq_addr ?" by MUFFIT::gerry (Gerry Reilly) Fri Apr 11 1997 07:48

I am seeing the following error message-

rpc__naf_desc_inq_addr:soc        7, status 4294967291

We are seeing this whilst doing fairly destructive of the new release of
our product.  

A process that is a rpc server is running on one system and a process that
is a rpc client on another.  The network connection between the two
system is broken and then after a couple of hours re-established.  The
break is done by an ifconfig down on the network adapter on the server
system responsible for the network connection between the server and
client.

There are also several rpc server <-> client connections running totally
within the server system.

After re-establishing the network connection we can do rpc's from
the client to server systems.  Unfortunately, we appear to have broken
rpc traffic within the server system.  Restarting the application clears
the problem.  It does not need a restart of DCE.

The configuration is using string binding.

This is DCE V2.0A (with early ECO1 kit) running on Digital UNIX V4.0A.

Two questions-

1. What does this error message mean ?

2. What are the likely consequences of it occuring ?

Cheers,

Gerry

T.R	Title	User	Personal Name	Date	Lines
2217.1	no worry	TUXEDO::CHUBB		`Fri Apr 11 1997 17:00`	26
	Gerry, I wouldn't worry about the message. We should clean it up so it makes a bit more sense. It's basically an errno resulting from a getsockname() call. I believe the errno got munged by reporting it as a DCE status. I don't think its a surprise considering you've taken down the interface -- just a matter of timing. As for your server failing after the reconnection of the interface, can you check the endpoint database at this point to see if the endpoints are still present for your server? % dcecp -c endpoint show Because dced has some threads dedicated to erasing endpoints that belong to servers that are no longer reachable, I think it might be expected that your endpoints have gone away. I'll file a QAR against the lousy message. -- brandon > I am seeing the following error message- > > rpc__naf_desc_inq_addr:soc 7, status 4294967291 >
2217.2		MUFFIT::gerry	Gerry Reilly	`Mon Apr 14 1997 05:32`	49
	Thanks for the quick reply. >> >> Gerry, >> >> I wouldn't worry about the message. We should clean it up so it makes >> a bit more sense. It's basically an errno resulting from a getsockname() >> call. I believe the errno got munged by reporting it as a DCE status. >> I don't think its a surprise considering you've taken down the interface -- >> just a matter of timing. Any chance of rippling the error up to the user API call ? That way the application could try for some recovery or close down in a controlled fashion. >> >> As for your server failing after the reconnection of the interface, can >> you check the endpoint database at this point to see if the endpoints >> are still present for your server? >> >> % dcecp -c endpoint show >> >> Because dced has some threads dedicated to erasing endpoints that belong >> to servers that are no longer reachable, I think it might be expected that >> your endpoints have gone away. I am happy that the endpoints associated with the communications over the now out-of-service interface are cleaned up. What worries me is that it appears to clean up the endpoints that are wholely within the system. This results in the application losing connection (and not being able to recover it) to an RPC based file service (SFS) that is running on the server system. Is this a consequence of the endpoint still being associated with the interface even though the RPC client and server are on the same system ? I do not know anyway of specifying a string binding that avoids a real interface because it appears that the RPC checks the interface when establishing the server (checks that it is UP and has certain capabilities). -- Any workaround ? -- Is this likely to change with local rpc support ? >> >> I'll file a QAR against the lousy message. >> >> -- brandon >> Thanks gerry