Using a java socket from JNI / C++ code

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

For your first question, if you have a java.net.Socket object reference in your JNI code, you can invoke methods on it, and so you can read and write data via the socket.

Answer 2

Your second question-

You can always 'bind' to the local interface you want (just need the the Ip address for it)

public void bind(SocketAddress addr) throws SocketExceptionBinds this DatagramSocket to a specific address & port

Answer 3

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.

Answer 4

Beware of solutions that poke around in JVM implementation specifics, they are liable to break in the future or with a different vendors VM. There is a way to do this portably using java.nio APIs. There are methods for communicating with channels from native code without copying buffers to/from the java heap.

The basic idea will be to create a java.nio.SocketChannel in your java code to open the connection. Then in the C++ use NewDirectByteBuffer to create a java.nio.ByteBuffer instance that can be passed to the read/write methods of the channel instance.

Look at JNI Enhancements Introduced in Version 1.4 of the Java 2 SDK and New I/O APIs for the details.

Answer 5

I can't think of a reason why Java would choose a ''better' local interface than th enative code. All it does is call the native code, very similarly to what you have yourself. You might be seeing something that is order-dependent rather than Java-dependent.