I'm trying to create a streaming client to display the video stream from an IP camera. At first I was using this GitHub project as a reference for my client. The issue I stumbled upon is that the example client uses DatagramPackets because it expects UDP to be the transport layer whereas my camera sends RTP packets over TCP. Wireshark seems to indicate that not only are the RTP packets sent over TCP, they are interleaved with RTSP packets.
I was therefore wondering how much of the example I could use since it is said in javadoc that DatagramPacket is used for connectionless protocols. Is the use of a streaming library advised in this case ? I heard about GStreamer and the like but it seemed really complex for what I was trying to achieve.
Related
I'm trying to implement RTSP protocol in Java according to http://www.csee.umbc.edu/~pmundur/courses/CMSC691C/lab5-kurose-ross.html example; I have succeed up to successful communication with VLC via RTSP requests and streaming RTP packets; RTP packets with JPEG payload are not recognized by VLC well; that's why I supposed I send malformed RTP. I sniffed them with wireshark and compared them with packets, sniffed from successfull RTSP communication of gstreamer RTSP streamer and VLc. I was surprised, that both my app&VLC's RTSP and RTP requests were labeled in wireshark UI as simply TCP and UDP packets, while gstreamer&VLC's one were labeled as RTSP, RTP, RTCP, and even RTSP/SDP.
I'm really confused, I don't understand why VLC's requsts in some cases are parsed by wireshark as pure RTSP/RTP, and im my case as plain TCP/UDP data. At least, VLC's requests are not malformed, even if my are.
How can I force wireshark to recognize that requests as some specific protocol?
Right click on a packet and select "Decode as...". Then choose "RTP" in the list of "Transport" protocols.
If you want to decode some custom-made protocol, you'll have to get or compile a dissector, which can be quite troublesome... Fortunately, PCAP format is simple and plugin directly to it is easy (I happened to just have made one last week, I might make it Open Source if my boss agrees).
Thanks to #GuyHarris who stated that automatic RTP decoding is performed when SDP packets are detected that initiate the RTP session. There also is an option in the "Edit > Preferences" menu, choosing "RTP" under the "Protocols" tree: "Try to decode RTP outside of conversations".
I've an application that's using Apache mina library for communicating based on TCP. The apache mina library provides a callback with IOBuffer that contains data coming over the network, however often times the data is received out of order or redundantly. I skimmed through the TCP protocol and it says that the protocol always ensures delivery of the data in correct order. The company that provided the APIs for their server claim that they are using TCP/IP for sending the response back however before sending the response back their server doesn't care about confirming if the client (in this case my application/apache mina library) is connected to the server. So the server just fires off the message and moves on.
If I'm not mistaken, that's the UDP protocol's behavior. My question is, if the server is using TCP for sending the response back:
Why do I get out of order data (it's rare but happens one in a while)?
How can a machine that's using TCP protocol just fire and forget about the data without making sure the receiver device is connected to it before sending the data?
Is this really TCP or UDP or some variation of TCP protocol?
Apache Mina does asynchronous messaging over the top of various transports including TCP.
Since Mina is asynchronous, out-of-order delivery should be expected.
Why do I get out of order data (it's rare but happens one in a while)?
One possible explanation is that multiple TCP streams are being used. Data delivered using one TCP stream will be delivered in order, but if multiple streams are used, data in one stream could "overtake" data on another stream, in the TCP stacks on the sending or receiving end, on the network, or in the client side library.
How can a machine that's using TCP protocol just fire and forget about the data without making sure the receiver device is connected to it before sending the data?
Because ... reliable delivery is not a basic attribute of Mina.
If you are using Mina to talk to a service with a particular application protocol, then that protocol will determine will determine whether "sending the data before checking the receiver is connected" is allowed / will work or not. For example, it won't for an HTTP response, because an HTTP response is sent on a connection that was previously established to send the request.
Actually, it seems that there are a variety of ways to use Mina. Some involve an application protocol; e.g. see HttpClientCodec and HttpServerCodec. Others don't.
Is this really TCP or UDP or some variation of TCP protocol?
If they say that TCP is being used as transport, then it is. However, Mina is neither TCP or UDP. It is Mina. It hides the details of the transport.
Bottom line, if you want the reliability / in-order delivery properties of TCP/IP, you should probably use them directly. Mina is providing higher performance than conventional TCP/IP over a synchronous socket by relaxing the normal properties of a (single) stream-based transport.
Basically I am new to server and client programming in java , I google all the necessary resources to learn from this particular topic however I did not understand the difference between them.
What I Understand so far for these two is that Both of them can Handle Client Request, but I need to further know the benefits of each Class and what particular scenario or specific case where when can I used it efficiently.
Like for instance , I have a Server Client Program which is a subset of team-viewer in which The client program must send Screenshot to the server in every millisecond while the server is going to publish it from another connected client. The code is working but I found out ServerSocket consumes so much Heap although it delivers successfully to the servers and client as well. I also read a blog (The link is missing) that is related to my problem suggested that DatagramSocket is the solution because it does not execute Handshakes.
I am really concern of the Benefits and Disadvantage of these classes.
A ServerSocket is for accepting incoming network connections on some stream protocol; e.g. TCP/IP.
A DatagramSocket is for sending and receiving datagrams on some connectionless datagram / message protocol; e.g. UDP/IP
Supplementary questions:
Basically what is a datagram
A datagram is bunch of information sent in a single logical packet. For example, a UDP packet.
and does this mean datagram = lightweight packets ?
It depends on your definition of lightweight!
UDP datagrams are sent as IP packets. If a UDP datagram is too big for an IP packet, it is broken into multiple IP packets by the sender and reassembled by the receiver.
and what does connectionless [mean],
It means that no logical connection exists between the 2 parties. If a component IP packet of a UDP datagram is lost, the UDP datagram is lost. The receiver never knows (at the application level). There is no reporting of data loss and no retrying in UDP. This is typical "connectionless" behavior.
does it mean Data might get lost during transmission?
Basically, yes. If you want reliable / lossless data transmissin the event that a datagram or on you should use ServerSocket and Socket; e.g. TCP/IP streams.
However, be aware that even with a (bare) TCP/IP stream, data delivery is not guaranteed:
If there is a network failure, or if either the sender or receiver has a failure, then a connection can be broken while data is in transit. That will result in data loss ... for that connection. (Sockets do not support reconnecting.) If the sender and/or receiver are still alive they will typically be informed that the connection has been broken, but they won't know why, or how much data was lost in transit.
It is possible for data to be corrupted in transit in ways that TCP/IP's error detection cannot spot. The receiver won't know this has happened.
Both of these issues can be addressed at the application protocol level; e.g. using message queues for the first and strong encryption and strong checksumming for the second.
Concerning your attempt to use ServerSocket.
The code is working but I found out ServerSocket consumes so much Heap although it delivers successfully to the servers and client as well.
You are doing something wrong. If you use the API appropriately the memory overheads should be insignificant.
My guess is that you are doing one or more of the following:
Opening a new connection for each client / server interaction
On the server side, creating a new thread for each connection
Not closing the connections.
I also read a blog (The link is missing) that is related to my problem suggested that DatagramSocket is the solution because it does not execute Handshakes.
Handshakes won't cause significant memory consumption.
TCP/IP stacks don't typically do handshakes by default anyway.
You say you have looked on google, but there are several pages on google that address your question directly. There are several that have the same title as your question. You have even indicated that you understand some of the difference between them by using the [tcp] and [udp] tags on your question.
The difference is one uses TCP communication protocol and one uses the UDP communication protocol. Perhaps your question is not one about Java but about how the internet, computer networking, and the communication protocols work?
TCP is a connection oriented reliable delivery protocol.
UDP is a connectionless unreliable delivery protocol.
What this means is you have to decide which is important, speed or reliability.
Is the data such that it must not be corrupted in transit? If it is then you must use TCP or a serversocket.
If the data must arrive by the fastest method, even at risk of getting lost, then you must use UDP or a datagramsocket.
If you need more explanation to understand you should take a course on computer networking.
I want to create a voice chat application in pure java socket programming.
I used UDP protocol to transfer recorded voice from one client to another but when i test it over the internet voice is not comming continuously.
As i am new to this voice chat application, someone may suggest what should i do for getting continuous voice.
The Scenario is like this.
Flow of voice chat as this shows only one way communication-
FLOW of data
Client1------------------------------>> Server ------------------------------------>>Client2
Client1:
Reading 1KB voice buffer from TargateDataLine then create a voice packet and sent to server.
Server: Receive from client1 and then send to client2.
Client2: Receive the UDP packet and get voice data then play.
Also facing the bandwidth up and down problem.
What should be the minimum bandwidth to use voice chat. Ex- skype required 30KBPS udloading/downloading speed.
Thanks in advance.
In order to establish a connection between two or more users for peer-to-peer communication you need a signaling server as well as STUN/TURN servers.
You can code your own ones or use a ready backend solutions like ConnectyCube and concentrate on client-side implementation. Here are some WebRTC video chat code samples for your reference as well.
You should send the packets directly between the clients. The relaying of packets through the server is adding more delay to it. Simply send it from client1 to client2.
The Answer is pretty simple you should use tcp protocol. Coz udp sends the packet but doesn't ensure that the packet was received by the target. but tcp protocol ensures it and you will get a stable connection with cost of some speed reduced in transfer of data.tcp vs udp
I have written a socket program in Java. Both server and client can sent/receive data to each other. But I found that if client sends data to server using TCP then internally TCP sends acknowledgement to the client once the data is received by the server. I want to detect or handle that acknowledgement. How can I read or write data in TCP so that I can handle TCP acknowledgement. Thanks.
This is simply not possible, even if you were programming in C directly against the native OS sockets API. One of the points of the sockets API is that it abstracts this away for you.
The sending and receiving of data at the TCP layer doesn't necessarily correlate with your Java calls to send or receive data. The data you send in one Java call may be broken into several pieces which may be buffered, sent and received independently, or even received out of order.
See here for more discussion about this.
Any data sent over a TCP socket is acknowledged in both directions. Data sent from client to server is the same as data sent from server to client as far as TCP wire communications and application signaling. As #Eric mentions, there is no way to get at that signaling.
It may be that you are talking about timing out while waiting for the response from the server. That you'd like to detect if a response is taking too long. Is it possible that the client's message is larger than the server's response so the buffering is getting in the way of the response but not the initial request? Have you tried to use non-blocking sockets?
You might want to take a look at the NIO code if you have not already done so. It has a number of classes that give you more fine grained control over socket communications.
This is not possible in pure Java since Java's network API all handles socket, which hides all the TCP details.
You need a protocol that can handle IP-layer data so you can get TCP headers. DLPI is the most popular API to do this,
http://www.opengroup.org/onlinepubs/9638599/chap1.htm
Unfortunately, there is not Java implementation of such network. You have to use native code through JNI to do this.
I want to detect or handle that acknowledgement.
There is no API for receiving or detecting the ACKs at any level above the protocol stack.
Rethink your requirement. Knowing that the data has got to the server isn't any use to an application. What you want to know is that the peer application has received it, in which case you have to get the peer application to acknowledge at the application protocol level.