We Keep Coding

Java Socket still first choice for TCP/IP programming in Java?

I need to interact with a server over TCP/IP with a basic message/response protocol (so for each request I shall receive a defined response).
In the JVM ecosystem, I think Java Socket was the tool to use 15 years ago, but I'm wondering if there is anything more suitable nowadays in the JDK? For example, with Java Sockets one still needs to manually timeout a request if no answer is received, which feels really old fashioned.
So is there anything new in the JDK or JVM universe?

No, there are much better option nowadays which allow you to implement your client/server asynchronously without additional threading.
Look at SocketChannel from nio or even better AsynchronousSocketChannel from nio2. Check this tutorial
Especially the latter option will allow you to just start the connection listener and register callback which will be called whenever new connection is requested, data arrived, data was written etc.
Also consider looking at some high level solutions like Netty. It will take care of the network core, distribute load evenly to executors. Additionally it provides clears separation of the network layer and processing layer. For the processing layer it will provide you with lot of reusable codecs for common protocols.

You can try RMI which works on top of TCP/IP but hides all the hardwork with a convenient set of APIs.
Follow this tutorial post

Well, there are really a lot of other technologies to use, for example JMS has various implementations which work out of the box.
Sockets are low-level building blocks of network communications, like wires in the electricity network of your house. Yes, they're old fashioned, yes, we likely don't want to see them, but they're there and they will stay there for a good reason.
On top of Sockets, you can e.g. pick the HTTPUrlConnection, which implements most of the HTTP protocol. Still, setting timeout policies are in your hands, which I find quite useful, and extremelly painful at the same time.
http://www.mkyong.com/java/how-to-send-http-request-getpost-in-java/
You are free to move one abstraction level above, and use a ready-made REST library, such as this: http://unirest.io/java.html
The example above connects to a server, configures a HTTP query string, perform the request (timeout, encodings, all the mess under the hood), and finally get the response in Json format in a few lines:
Unirest.post("http://httpbin.org/post")
.queryString("name", "Mark")
.field("last", "Polo")
.asJson();
Nowadays a vast amount of web services are available using REST protocol, which is a simple command-response over HTTP. If you have a chance, I'd suggest using REST, as you can easily find available client and server side implementations, and you don't need to reinvent the wheel on the command-protocol layer either.
On client side, unirest is quite convenient. On the server side, we have had really great experience in the 1.2.xx series of Play! framework. But there are thousands of these things out there, just search for "REST".

Take a look to Netty Project, "Netty is a NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server."
This framework give us a lot of capabilities that simplify the programming process, allowing a big scalability.
Is used by Twitter and a lot of big companies in the tecnology industry.
This is a nice presentation from Norman Maurer.

High Level Protocols for Bluetooth/WiFi Direct Sockets?

When you work with Bluetooth or WiFi Direct in Android, at the end of all of the handshaking and such, you wind up with sockets.
With TCP/IP, we have a zillion-plus-one libraries that layer on top of sockets, for high-level protocols: HTTP, XMPP, IMAP, etc. Courtesy of these libraries, we can deal with more domain-specific abstractions of an operation (e.g., "download this file"), with low-level socket plumbing handled by the library.
Question: Are there equivalents, for any high-level protocol, that are known to work (or are likely to work) with the sockets produced via Android's Bluetooth and/or WiFi Direct layers?
Right now, I'm not fussy about the specific protocol -- I'm just looking for examples of this sort of protocol layer, to make using these sorts of connectivity options easier for developers.
For example, it looks like I could create a fork or add-on for OkHTTP that uses an alternative source for sockets, and I could probably create a Java HTTP server that does the same. Given those, app developers would write HTTP apps that talked over Bluetooth or WiFi Direct (and, on the client side at least, the coding should be fairly "natural" in feel, once the connectivity-specific pairing and handshaking has gone on).
IOW, going back to dealing with raw sockets feels so two decades ago... :-)
Thanks!
UPDATE
Based on Kristopher Micinski's comment on the ZeroMQ answer, I figured some clarification might be in order.
It's easier to say what I don't want: I don't want to touch sockets, after creating them. Something else at a higher level should handle those for me, plus handle what I'd consider a "protocol" to be (e.g., determining when some communications operation has ended, beyond a socket closing).
Mostly, this is for my book. Most book examples for low-level socket stuff are unrealistic, such as "we open a socket to the server and immediately start blasting the bytes representing some image to be uploaded, then close the socket when we're done". While the examples work, you'd never write something like that in real life:
If you're really working at the socket level, you'd be implementing some protocol that has the hopes of addressing authentication, error handling, etc., even if you're rolling the protocol yourself
Few developers work directly with sockets today for Internet operations
Now, it'd be cool if the protocol offered by the layer were something developers were used to (e.g., HTTP) or had heard of even if they haven't used it (e.g., XMPP). And I'll settle for simple scenarios (e.g., N-way support is cool but not necessary). In this respect, based on preliminary research (conducted by a sleep-deprived brain), ZeroMQ isn't a bad option. It lacks a bit of "brand recognition" compared to, say, an XMPP stack that could work with arbitrary sockets. But off the cuff it seems to meet what else I'm looking for.
I recognize that these stacks will have limitations imposed by the underlying transport (e.g., Bluetooth works well for N-way only for small values of N). And I certainly don't want to portray -- here or in my book -- that whatever solution I portray is the be-all and end-all of socket based communication.
I just want something that has a prayer of being more realistic for actual use. Bonus points if it is something that I can grok, as I have always used higher-level protocols for TCP/IP communications, and so I'm short on experience with direct socket manipulation.

I found ZeroMQ to be useful for managing socket connection. They have a support in multiple languages which includes JAVA. You may use this to manage the sockets once you establish the connection over wifi-direct or BT.

I know it's a somewhat old question and already answered but I would like to contribute.
I did this app: https://play.google.com/store/apps/details?id=com.budius.WiFiShoot and although the WiFi Direct connection n handshake is somewhat broken and it's what causes most of my unhappy users, I'm handling all the communication using the excellent https://github.com/EsotericSoftware/kryonet
and my code is pretty much what you see on their examples, create kryo, register classes, open server, connect client to server IP and shoot objects across with the file information and later I shoot the actual files using this code https://code.google.com/p/kryonet/source/browse/trunk/kryonet/test/com/esotericsoftware/kryonet/InputStreamSenderTest.java
hope it helps.

Java Sockets Direct Protocol

As we know the Sockets Direct Protocol (SDP) provides access to high performance network connections, such as that provided by InfiniBand
can any one please give me any good example of how can i use Sockets Direct Protocol (SDP) of java ?

If you are running a recent version of Solaris or OpenSolaris I think you are all set to try stuff out.
Linux requires use of the libsdp library and external kernel modules available from OpenFabrics (OFED), there seems to be strong desire to get the modules into Linux mainline but OFED guys seem to be rubbing the kernel developers up the wrong way over some of the issues involved.
There's a useful setup guide for Infiniband under Debian Linux which gives details on how to set up and compile the OFED kernel modules and the libsdp library etc. Once you have that done you can follow the SDP section of that how-to in order to get SDP working and tested.
After that I think it is as simple as getting a recent JDK7 snapshot, currently at M12, and trying stuff out. Set up your config and create connections between addresses specified in your SDP config, all done via the same APIs as network sockets, i.e. Socket for 'old' IO, and SocketChannel for NIO (or even AIO in JDK7 :). As far as I can see, once you have followed the set up guides and configured the addresses that will use SDP the JVM will use SDP based Sockets/SocketChannels whenever you provide addresses within the SDP mapped range. So your existing networking code that uses sockets should be able to use the SDP connections transparently, just at blazingly fast speeds and tiny latencies.
Windows users are out of luck for the time being, as far as I can tell.
Also:
Alan Bateman's SDP blog entry (Oracle JDK SDP lead)

Java P2P - what options are there?

I'm looking to write a decentralised application that would run over some kind of peer to peer framework. I have fairly limited requirements:
search for peers offering a particular service
advertise services
connect directly to other nodes
operate across NATs (so support relay and rendevous)
I know about JXTA, but what other options are there? JXTA seems like a bit of a nightmare to implement - is there anything else that maybe offers a less complete protocol stack in exchange for simplicity and ease of deployment?
Thanks

JXTA is something matured p2p overlay implementation. I'm using Pastry (its also written in java). Surf Pastry and have fun...:)

Sounds like something XMPP (Jabber) could solve. Its not true P2P (it has servers), but the servers are inter-linked and mature.

Take a look at pne of theses options :
Azureus : http://azureus.sourceforge.net/
XNAP: http://xnap.sourceforge.net/screenshots.html

Netty vs Apache MINA

They both provide roughly the same functionality. Which one should I choose to develop my high-performance TCP server? What are the pros & cons?
Reference links:
Apache MINA (source)
Netty (source)

While MINA and Netty have similar ambitions, they are quite different in practice and you should consider your choice carefully. We were lucky in that we had lots of experience with MINA and had the time to play around with Netty. We especially liked the cleaner API and much better documentation. Performance seemed better on paper too. More importantly we knew that Trustin Lee would be on hand to answer any questions we had, and he certainly did that.
We found everything easier in Netty. Period. While we were trying to reimplement the same functionality we already had on MINA, we did so from scratch. By following the excellent documentation and examples we ended up with more functionality in much, much less code.
The Netty Pipeline worked better for us. It is somehow simpler than MINAs, where everything is a handler and it is up to you to decide whether to handle upstream events, downstream events, both or consume more low-level stuff. Gobbling bytes in "replaying" decoders was almost a pleasure. It was also very nice to be able to reconfigure the pipeline on-the-fly so easily.
But the star attraction of Netty, imho, is the ability to create pipeline handlers with a "coverage of one". You've probably read about this coverage annotation already in the documentation, but essentially it gives you state in a single line of code. With no messing around, no session maps, synchronization and stuff like that, we were simply able to declare regular variables (say, "username") and use them.
But then we hit a roadblock. We already had a multi-protocol server under MINA, in which our application protocol ran over TCP/IP, HTTP and UDP. When we switched to Netty we added SSL and HTTPS to the list in a matter of minutes! So far so good, but when it came to UDP we realised that we had slipped up. MINA was very nice to us in that we could treat UDP as a "connected" protocol. Under Netty there is no such abstraction. UDP is connectionless and Netty treats it as such. Netty exposes more of the connectionless nature of UDP at a lower level than MINA does. There are things you can do with UDP under Netty than you can't under the higher-level abstraction that MINA provides, but on which we relied.
It is not so simple to add a "connected UDP" wrapper or something. Given time constraints and on Trustin's advice that the best way to proceed was to implement our own transport provider in Netty, which would not be quick, we had to abandon Netty in the end.
So, look hard at the differences between them and quickly get to a stage where you can test any tricky functionality is working as expected. If you're satisfied that Netty will do the job, then I wouldn't hesitate to go with it over MINA. If you're moving from MINA to Netty then the same applies, but it is worth noting that the two APIs really are significantly different and you should consider a virtual rewrite for Netty - you won't regret it!

Update: Just use Netty. It is now a mature project with all the bells and whistles required for building protocol clients and servers. It has strong community with several active contributors backed by enterprises. It also has a book, 'Netty in Action'. It has been adopted by many many well-known companies and projects already. Unlike Netty, Apache MINA has been under maintenance mode since I left the project.
MINA has more out-of-the-box features at the cost of complexity and relatively poor performance. Some of those features were integrated into the core too tightly to be removed even if they are not needed by a user. In Netty, I tried to address such design issues while retaining the known strengths of MINA.
Currently, most features available in MINA are also available in Netty. In my opinion, Netty has cleaner and more documented API since Netty is the result of trying to rebuild MINA from scratch and address the known issues. If you find that an essential feature is missing, please feel free to post your suggestion to the forum. I'd be glad to address your concern.
It is also important to note that Netty has faster development cycle. Simply, check out the release date of the recent releases. Also, you should consider that MINA team will proceed to a major rewrite, MINA 3, which means they will break the API compatibility completely.

I performance tested 2 "Google Protobuffer RPC" implementations where one was based on Netty (netty-protobuf-rpc) and the other based on mina (protobuf-mina-rpc). Netty ended up being consistently faster ( +- 10% ) for all message sizes - which backs up the overall performance claim on the Netty web site. Since you want to squeeze every bit of efficiency out of your code when you use such an RPC library, i ended up writing protobuf-rpc-pro based on Netty. I have used MINA in the past, but find their documentation of the 2.0 stuff has big holes, and the breaking of API backward compatibility a big minus.

MINA and Netty were initially designed and build by the same author. That's why they are so similiar to each other.
MINA is designed at a slightly higher level with a little more features, while Netty is a little faster.
I think that there's not much difference at all, the basic concepts are the same.

In Netty site you can find some performance reports. As expected :-) they point out Netty as the framework with the best performance.
I never used Netty, but I already used MINA to implement a TCP protocol. The implementation of encoding and decoding was easy, but the implementation of the state machine was not so easy. MINA provides some classes to aid you when implementing the state machine, but I found them kind of hard to use. In the end we decided to ditch MINA and implement the protocol from scratch, and surprisingly we ended with a faster server.

I use Netty.
Twitter also chose Netty to build its new Search System and made it 3x faster.
Ref: Twitter Search is Now 3x Faster
We chose Netty over some of its other competitors, like Mina and Jetty, because it has a cleaner API, better documentation and, more importantly, because several other projects at Twitter are using this framework.

I've only ever used MINA to build a small http like server. The biggest problems I've run into with it so far:
It will hold your "request" and "response" in memory. This is only an issue because the protocol I choose to use is http. You could use your own protocol however to get around this.
No option to provide a stream off disk in case you want to serve up large files. Again can be worked around by implementing your own protocol
Nice things about it:
Can handle a lot of connections
If you choose to implement some sort of distributed work system then knowing when one of your nodes goes down and loses connection is useful for restarting the work on another node.