Question

I have a java app that creates a socket to talk to a server process, eg new java.net.Socket(String host, int port). This app includes a bunch of legacy c++ code that needs to suck gobs of data from that server and process it. This is currently implemented by having the native code create its own socket and connect to the server, eg:

sock = socket(AF_INET, SOCK_STREAM, 0);
struct hostent* hp = gethostbyname(host);
if (!hp)
{
  unsigned long addr = inet_addr(host);
  hp = gethostbyaddr((char *)&addr, sizeof(addr), AF_INET);
}

struct sockaddr_in name;
name.sin_family = AF_INET;
memcpy(&name.sin_addr, hp->h_addr, hp->h_length);
name.sin_port = htons(port);

connect(sock, (sockaddr*)&name, sizeof(name));

On Windows vista/7 machines with multiple NICs (eg wired and wifi or vpn connections), these two sockets can end up with different local addresses. The java code appears to choose a “better” interface (the wired Gb enet = higher MTU?), the native (naive?) code gets the “default” interface (stick in a usb wifi device and it becomes your default – yuck).

This causes some problems for me, I don’t think the details are relevant. Two questions:

1. Is is possible for me to re-use the java socket from the JNI code (portably? assume Sun JDK). This would avoid the issue completely, but so far I don’t see any way to interact with the java.net.Socket stuff from JNI/native code.

2. Since the answer to the first question is probably NO, how is java creating that socket (choosing the interface) ? Code snippets welcomed. I have looked around in the openjdk stuff and haven’t found what I am looking for.

Thanks,
Chris

Answer 1

To answer your first question: if it’s possible to reuse Java’s socket from within the native code — yes it is possible, but I would not recommend it (you would tie yourself to the internals of a specific implementation/version); but if you really must: use reflection to get access to java.io.FileDescriptor on the java.net.SocketImpl then use sun.misc. JavaIOFileDescriptorAccess’s get method to get the native socket descriptor. Checkout DualStackPlainSocketImpl.java)

To answer your second question: what’s Java’s algorithm to find the default interface on windows — checkout getDefaultIPv6Interface method in net_util_md.c (don’t let the v6 fool you — i believe it’s used for v4 as well).

I would advise that you open and use the socket either from the C (JNI) code or from the Java code, preferably the later, as you’ll find that cleanup and error handling is best handled in the code that manages the socket. The idea of opening the socket in Java and passing byte buffers from C (JNI) is perfectly sane, and you should not find any problems with the heap on reasonable buffer sizes and proper deallocation in the JNI code.

Think Java application servers that handle huge amounts of data without a hitch.