Hi James and Kacheon,
Many thanks for your helpful information.
After checking the parameter type of /'length//'/ for /accept(3socket)/
and /getsockopt(3socket)/, we find the ISV program use '/unsigned long/'
which is wrong when this program is compiled to 64-bit executable file.
We also find this case will just happen when we build this code into
Tuxedo service.
It's a client code flaw. I will keep this mail thread updated if we find
out whether there is problem with Tuxedo.
Regards,
Adam
James Carlson wrote:
Adam Zhang writes:
We met a very strange behavior of accept(3socket) and
getsockopt(3socket) in our ISV program that uses TCP Stream socket and
is based on Solaris 9 + Tuxedo 8.1 + Sun Studio 11.
Solaris 9 isn't Open Solaris. (Nor is Solaris 10, for that matter.)
- After the accept function, we can't get the client's ip address, even
we call the getpeername. But we can still use this socket to communicate.
Without seeing the source code in question, it's hard to say exactly
what might be wrong. However, a fairly common reason for this sort of
problem is that the coder forgot that the 'length' argument (third
argument for accept(3SOCKET) and getpeername(3SOCKET)) is actually an
"in-out" parameter.
This means that you *MUST* set the value before making the call, and
may check it afterwards.
struct sockaddr_in sina;
socklen_t alen;
alen = sizeof (sina);
newfd = accept(listenfd, (struct sockaddr *)&sina, &alen);
If you don't set 'alen' to some reasonable value, then the call can
fail.
- For the getsockopt function, it can't get the value with SO_SNDBUF
while the program can set setsockopt with SO_SNDBUF. The errno will be
set to EINVAL after calling getsockopt
and we check the arguments by using the dbx.
This sounds like the same coding flaw to me. The fifth argument is an
in-out parameter.
_______________________________________________
networking-discuss mailing list
[email protected]
