We Keep Coding

TCP transport for grpc-java

Is there an implementation of raw TCP transport for grpc-java? I need grpc for internal network services and don't have firewall issues so I'd like to avoid HTTP/2 overhead when building grpc based services.

"Raw" TCP is not actually a thing. You need to build a protocol on top. It happens that HTTP/2 is very close to any proprietary protocol gRPC might make. I'll also note that gRPC integrates closely with HTTP/2, so HTTP/2 is viewed as part of gRPC within many implementations and can be optimized as one unit.
gRPC needs multiplexing, flow control, byte-based framing (not message-based), and metadata. And that's basically what HTTP/2 is at its heart. You can make simpler protocols, but then you begin having issues with large messages causing head-of-line blocking, memory usage, or frequent TLS connection establishment costs.
Making a protocol with those features is a very well understood problem. HTTP/2 actually looks more similar to TCP than HTTP/1 in many respects. And it solved the problems in mostly the same way as SSH-2.
The "losses" by choosing HTTP/2 are small. Things like required headers used in grpc, like method name and status code, can't be optimized directly into the protocol as a struct instead of generic metadata. But HPACK can help some there. Native binary headers would be really nice, to avoid base64-encoding metadata, although it would be relatively easy to extend HTTP/2 to support that via a SETTINGS negotiation.

Is it possible to initiate http2 session or stream from Jetty Assuming a http2 connection already exists?

It is possible to do server push. But if the client is the low-level jetty client, is it possible to initiate a new session or stream from the server? the assumption is the client is low-level jetty based client and the connection is already established.

After the initial connection is established, and the prefaces exchanged, HTTP/2 is a symmetric protocol.
The HTTP semantic requires the client to initiate requests, but at the lower level - at the HTTP/2 protocol framing level - this is not necessary and it is possible for a server to initiate a stream towards a client.
While the HTTP/2 protocol framing is symmetric after the preface, it is still tied to the HTTP protocol semantic, that is you need to send a HEADERS frame (even an empty one) before a DATA frame. However, this may not be of much hindrance if you want to build your own protocol on top of the HTTP/2 framing, you will just have few additional bytes to send over the network.
As an aside, there are proposals that use the HTTP/2 framing to transport WebSocket (a pure bidirectional protocol) frames inside HTTP/2 DATA frames, in what is essentially an infinite request with an infinite response. But I digress.
As for the Jetty specific implementation of HTTP/2, is it possible to initiate a stream from the server towards a client in Android ?
The answer is two-fold.
The first is that the current implementation (Jetty 9.3.8) has some assumption that the protocol being transported by the HTTP/2 framing is HTTP. As such, a server-initiated stream is currently dropped by the client.
It would be fairly easy, though, to override this behavior and allow the client to properly handle the server-initiated streams, in the same way the server handles client-initiated streams.
The second is that Jetty's HTTP/2 support in general requires JDK 8, and at this time this is not available in Android.
If there already exist HTTP/2 Android clients that are capable of handling server-initiated streams, please comment on this answer which one, as I am really interested.
The idea of server-initiated streams is intriguing though, and I filed this issue to keep track of it.
If this is really important to you, you can contact Webtide (the company behind Jetty) to sponsor the implementation.

How is using TCP communication better than HTTP communication?

I have implemented a client server jave program using TCP for an assignment. Now I've to explain why I chose TCP for communication when other alternatives like HTTP are also available..
So I need some reasons why TCP is better than the other one ..

HTTP is not an alternative to TCP. It is a protocol built on top of TCP.
Custom, interactive protocols can be much more efficient when implemented on TCP than on HTTP, because HTTP works on a rather basic request/response base.
On a pure TCP connection, both ends can send messages whenever they want. On HTTP the server can't really proactively send a message to the client. It needs to wait for the client to send a request.
An advantage of HTTP is that it's almost universally understood: there are server- and client-libraries for all languages, there are well-understood caching and proxy-ing mechanisms and there's a wide variety of content negotiation-mechanisms built in.
So it's the traditional trade-off between high-level or lower-level abstraction:
lower-level abstraction (TCP) provides high flexbility and the possibility of implementing almost everything, while it is not as simple to use
higher-level abstraction (HTTP) provides more built-in features and are easier to support, but additional features are harder to add

HTTP is a protocol on top of TCP. It offers specific features and lacks others (most significantly statefulness and the ability for servers to initiate communication). If you need something that HTTP makes hard or impossible, it would be a good idea to use something else.
Or you can kludge those features on top of HTTP, which is what seems to be the most popular option (possibly because of the "only port 80 is open everywhere, so let's use it for everything" issue) but often leads to rather nasty hacks.

TCP can't be told as better. It is a protocol of transport(4th) level of OSI model.
HTTP is an application protocol(7th level).
They are different and HTTP is based on TCP.
HTTP is basically used for web communications - sites, web-services and so on. It can be told that HTTP is a client-oriented: client asks server for some data and receive the response. When it sends another request and so on.
TCP is a base protocol which grants you that all your sent information will be received in the same order and intact.
Read about them on Wiki: HTTP and TCP.

Good TCP connection library for Java?

I am looking for a good TCP connection library from Java with the following facilities:
1. Retry on failed publishes
2. Multiple connections
Which library have you sucessfully used.
EDIT: Based on the comment changed the question to reflect which type of connection library.

May be Apache MINA will help you.Have a look .

I'm not sure this really makes sense. You're talking about retrying on failed publishes, yet TCP doesn't have a concept of publishing. Merely message transfer. So you could be publishing, or you could be requesting info.
e.g. HTTP over TCP has the verbs GET/PUT/POST (amongst others). All of these run over TCP. Only two actually write something (PUT/POST). And only PUT is supposed to be idempotent (that is to say, you should be able to the same operation again and again with the same result). If you POSTed repeatedly, I'd expect to republish something and create a new version on the server for every POST.
And the above are only recommendations for how PUT/POST are implemented. I wouldn't want an HTTP library to assume this on my behalf.
So the concept of retrying messages at the TCP layer is mistaken (note that TCP will resend packets etc. making up a message). This is a higher-level function, which may use TCP at a lower level. e.g. I've written my own wrappers around HTTPClient to retry PUTting when my remote server becomes temporarily unavailable or reports an error (I'm not sure a retrying HTTP library exists)

Maybe this help others, Try this library called socketal, Pure Java uses ServerSocket and Socket, it's pretty simple and doesn't have any unnecessary feature.
This library is capable of:
Autoreconnect on disconnection
Capable of handling Connecting/Disconnected/Connected
Pretty simple to send String, Object or File
Set your own Authentication code and Verification just like Login Password
It's seems like the Netty but these doesn't have a lot of complicated setup and features.
It's compatible for Android/Java.

How do I know WHEN to close an HTTP 1.1 Keep-Alive Connection?

I am writing a web server in Java and I want it to support HTTP 1.1 Keep-Alive connections. But how can I tell when the client is done sending requests for a given connection? (like a double end-of-line or something).
Lets see how stackoverflow handles this very obscure question -- answers for which, on Google, are mired in technical specifications and obscure language. I want a plain-english answer for a non-C programmer :)
I see. that confirms my suspicion of having to rely on the SocketTimeoutException. But i wasn't sure if there was something i could rely on from the client that indicates it is done with the connection--which would allow me to close the connections sooner in most cases--instead of waiting for the timeout. Thanks

If you're building your server to meet the standard, then you've got a lot of information to guide you here already.
Simple spoken, it should be based on a time since a connection was used, and not so much at the level of request data.
In a longer-winded way, the practical considerations section of the HTTP/1.1 document has some guidance for you:
"Servers will usually have some
time-out value beyond which they will
no longer maintain an inactive
connection. Proxy servers might make
this a higher value since it is likely
that the client will be making more
connections through the same server.
The use of persistent connections
places no requirements on the length
(or existence) of this time-out for
either the client or the server."
or
"When a client or server wishes to
time-out it SHOULD issue a graceful
close on the transport connection.
Clients and servers SHOULD both
constantly watch for the other side of
the transport close, and respond to it
as appropriate. If a client or server
does not detect the other side's close
promptly it could cause unnecessary
resource drain on the network."

Lets see how stackoverflow handles this very obscure question -- answers for which, on Google, are mired in technical specifications and obscure language.
I just put When should I close an HTTP 1.1 connection? into Google, and the third hit was HTTP Made Really Easy. In the table of contents, there is a link to a section entitled Persistent Connections and the "Connection: close" Header. This section is three paragraphs long, uses very simple language, and tells you exactly what you want to know.
I want a plain-english answer for a non-C programmer :)
With all due respect, programming is a technical endeavour where the details matter a great deal. Reading technical documentation is an absolutely essential skill. Relying on "plain English" third-party interpretations of the specifications will only result in you doing a poor job.

You close it whenever you'd like. The header indicates that the client would prefer you to leave the connection open, but that doesn't require the server to comply. Most servers leave it open for about 5-10 seconds, some don't pay attention to it at all.

You should read the RFCs dealing with the Keep-Alive feature. Otherwise you might end up with a server that doesn't work as expected.
As #[Stephen] has already pointed out, the server is free to close the connection anytime it wishes (ok, not in the middle of a request/response pair though). Ditto for the client. Any other solution would allow the server or the client to perform a DoS on the other party.
EDIT: Have a look at the Connection header. The client (and the server) can request a graceful connection closure using the header. For example, Connection: close inside the request is a request to the server to close the connection after it sends the response.