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.
Related
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.
I have developed an embedded system which sends data to a server as TCP requests. I can't use more-frequent HTTP requests, because of its data overhead. Less package length will result in less energy consumption and less communication expenses.
The server has to listen to a special port, get the data from device and store in a table.
As I explored, Java servlets + Apache Tomcat is a popular solution but in this case should not be used, because a Java servlet is more suitable for HTTP-based connections.
Is there a better solution for this type of communication?
Please take a look at Sockets. They are on the Application layer TCP/IP model and they provide reliable, bidirectional communication, with no data overhead. However, you will need to design a tiny protocol for the communication to much your needs.
Most probably this will suffice your needs, but if you decide to go with the HTTP solution, keep in mind Websockets which is an interesting solution, will diminish the overhead of the HTTP protocol (but they won't eliminate it, the overhead will remain at around 2-10 bytes.). Unfortunately, Java SE doesn't built in provide support for Websockets so you will need to use an external library.
PS: Both options support encryption over TLS but I didn't mention it, cause it adds a noticeable overhead (at least during the initialization of the connection)
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.
Is there a way in Java to know if an HTTP request was received over TCP or over UDP?
Quote from the RFC2616
HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80 [19], but other ports can be used. This does
not preclude HTTP from being implemented on top of any other protocol
on the Internet, or on other networks. HTTP only presumes a reliable
transport; any protocol that provides such guarantees can be used;
the mapping of the HTTP/1.1 request and response structures onto the
transport data units of the protocol in question is outside the scope
of this specification.
I would say this eliminates default UDP. Other Reliable forms of protocols would still be possible
As #ceekay says, RFC tells that HTTP uses reliable transport only, so that means no way for UDP. But one may try to build some other protocol on top of UDP, or may be do not use TCP/IP stack at all..
But as your question is about Java, then the answer is - this is all about Java libraries and frameworks used. Actually all the libraries that I know, like HtmlUnit http://htmlunit.sourceforge.net for example, hide this information from you. So you are dealing with HTTP(s) only without knowing details about underground transport. But in theory this is possible that some library will show this information for you.
But actually I do not see a way why this may be importatnt for you (in 99.999999% HTTP will use TCP). If you tell us why you are asking that strange question, then maybe we will answer you more specific.
I am about to write a client-server application (a simple game) and I want to use Erlang for the server side and Java for the client side. How should I make the connection between client and server? I have never worked with network programming before...
I think that "sockets" is the thing that I should use, am I right? In that case, could I use Java's sockets-class to send/recieve messages on the client and some corresponding sockets-module in Erlang on the server? Or do I have to have some kind of Java receiver on the server and then translate to Erlang? Is sockets some general protocol sent over the network that all languages interprets?
Depends on what you want to learn.
Sockets are low level and you will need design a protocol.
HTTP Rest API is more general, requires web server (yaws for example)
or Jinterface Erlang<->Java bridge
http://www.slideshare.net/dennisbyrne/integrating-java-and-erlang-with-jinterface-presentation
Indeed, Erlang provides a module for Socket programming that you can use. Go with your option number one.
But is such low level programming is a must for you? If not for your game, then consider creating a REST API. It is HTTP after all. Thus you can achieve:
general protocol sent over the network that all languages interprets
Another alternative to sockets and HTTP for creating
some general protocol sent over the network that all languages interprets
is something like Apache Thrift or other interface description languages (IDL). While it doesn't support all languages, it does support both Java and Erlang.