I am developing an Android application with Unity3D (C#) that captures frames from the camera (~30fps) and sends them to a computer on a network. The frames received by the computer will then be processed with an OpenCV-based program (C++). I managed to implement this using UDP socket (also tried TCP but some frames get lost sometimes). Later, I found out that some networks stop UDP packets for security reasons (like inside my company), so I would like to generalise the communication by creating a different interface, e.g. via HTTP POST. Will this make sense? I don't have much experience with HTTP requests and I was wandering whether this approach will be similar the TCP-socket case, that wasn't successful.
Are there other communication means that can guarantee performance like UDP, but by making the communication at a higher level?
There are two types of socket protocols... TCP and UDP. HTTP is an application protocol that is run on the data received over a TCP socket. So you cannot replace TCP or UDP with HTTP. You will use HTTP with a TCP or UDP socket.
Now there is something troubling with your post... TCP sockets are by far the more reliable. It does not make sense that frames get lost when using TCP, since TCP essentially guarantees that you will get all of your data out.
With UDP, on the other hand, you will often find that many packets get dropped. Actually, for video streaming that is not a totally bad thing. For video streaming, you want to reduce the latency as much as possible. TCP has to do a lot of error checking to ensure that your packets don't get dropped, and so TCP is much slower than UDP. Hence for video streaming, you will typically use UDP.
In any event, there are much more efficient libraries for streaming video than simply trying to implement your own with UDP and jpeg frames. I would recommend you search for one that meets your platform and language needs.
Related
I have an application that processes a 10 second audio clip and was wondering if it would be faster to use a custom TCP socket to send the processed audio clip recorded from the mic to a server rather than using HTTP?
It depends heavily on the purpose of your transfer.
If you are transmitting, playing, and discarding the sound, then use UDP transfer.
If you are sending the file as a binary blob file, then both protocols are being used (remember that HTTP is built over TCP/IP)
If you are sending the file directly over a TCP connection, the overhead is marginally smaller then the HTTP header added. (I would suggest around 30~10% increase in binary transfers, from my experience)
Edit:
Like you said it pretty much gets discarded immediately after sending.how will I guarantee the arrival of the file though without TCP. Would I need to implement my own acknowledgements?
You will not guarantee the arrival. That is basically the difference between TCP and UDP. If your purpose is to be "stream-like" behavior, and you are fine with loosing some part of the content, then UDP is great, since a "second" worth of information lost is not relevant to the continuation of a conversation, in a phone, this would be similar to hiccups or sharp noises in the call.
However, if you are required to ensure that every bit and byte must reach its destination, then TCP is necessary.
Finally, regarding to HTTP and TCP, TCP will always be "smaller" than HTTP, but overall their sizes will not be significantly different. Specially if you intend on performing some HTTP funcionality that TCP does not directly implement.
I don't think anyone would be able to measure a difference either way.
If you send the file in one request the overhead of http will be quite small. Normally the overhead on http is mostly creating a large number of connections but since you will only be making one you should be in the clear.
I am implementing a real time - multi user voice transfer application for Android.
I have read that, as a standard - RTP packets are encapsulated into SIP and then sent to destination(s). What is the advantage of doing so?
my idea was to use a server, just to receive control messages from nodes and open sockets. All these nodes would be in 1 group. THen, I send out the IP addresses of each of these nodes, so that a single sender can multicast its packets directly to the destination.
is there a fatal flaw here? ( iam not concerned about the power consumption)
How does SIP do better? or does it ?
Thanks
RTP isn't "encapsulated into SIP packets". SIP is a signalling protocol. RTP is a media stream protocol. SIP is used to negotiate and set up (and tear down) media streams.
TCP is a horrible choice for media (RTP) packets; it's not clear from your writing if you're suggesting that.
Multicast is unlikely to work for many network paths/recipients.
routers play merry hell with incoming data; you'll need more than just SIP to deal with users on the open net. See STUN, TURN, ICE, UPnP, etc.
SIP or Session Initiation Protocol is a protocol that was designed specifically to address the problem you're trying to solve. Generally, the reason you should reuse (rather than reinvent the wheel) is because other people have studied the same problem and presumably have come up with a better solution as a collective group than you could as an individual. Of course that's not always true, but generally speaking it holds!
If you want to learn about SIP you could study the RFC 3261 specification, or start with the Wikipedia entry if you want a quick overview.
That being said, if you don't need the overhead of a complete and carefully tested protocol you could roll your own but make sure that when you're making that decision you know what you're foregoing and have a good reason to do so.
SIP is a signaling protocol that usually runs over TCP (although not required) and if you look at it closely you will see it is very similar to HTTP in many respects. Just like HTTP it can transport a great deal of payloads and it does so with text headers, much like HTTP can be used to transport HTML, XML, plain text or any arbitrary binary payload.
In the most simple system, you could just use Voice packets over RTP over UDP.
But you'd have no way to turn audio off, and would have to know IP addresses, port numbers, they type of codec and its characteristics beforehand.
In an overly simple view, SIP is a way to:
1. find the ip address of another endpoint from a URL. (May need STUN, TURN, ICE, etc)
2. agree on which codec to use and its options
There's a lot more to SIP than that, you may want to investigate SIP's conferencing features based on what you wrote.
You may write your own signaling protocol, and if this is for a school project, that will work just fine.
But if you are doing a commercial project, bear in mind that there is a lot more to telephony than meets the eye. The original SIP spec was greatly revised and is now a cluster of RFCs which are still being modified and added to. I recommend that you take advantage of this work rather than possibly reinventing the mistakes others have made.
I need some suggestion here. Do you think UDP is a better choice for sending the files from one pc to another or say from one device to another like iphone, android etc?
regards
Your question title says "video streaming", for which UDP is an appropriate choice. UDP does not guarantee packet delivery, but this doesn't really matter for video streaming.
The body of your question, however, says "sending files", which isn't exactly the same as streaming. If you're trying to transfer whole files from one device to another (and it's important that the entire file makes a successful transfer), then TCP is the way to go.
This is hard to intepret.
In the title, you talk about "streaming", but in the body you say "files".
Streaming is best done using UDP, since TCP always delivers data in order: if a packet is lost and must be re-send, the application won't get any data until TCP has solved it. For real-time data, this is undesirable.
Files are better sent using TCP.
Start to look at UDP when you wish to send to multiple recipients and the cost of throwing multiple boxes at the problem becomes excessive.
So assess the situation, the development cost of a UDP transport is higher to significantly higher than TCP and to some degree you are re-inventing TCP. The benefit of multicast is obvious, but what benefits are there for unicast? On modern hardware you have TCP acceleration which means UDP unicast is actually quite an expensive alternative. The arguments of lower latency are for specific applications, i.e. gaming, and more importantly are linked to lack of reliability and low capped data rates.
NB: The initial performance differential developers see between TCP and UDP is Nagle's and TCP slow start, i.e. congestion control, which is critical to scalability of inter-networks. Both can be disable for internal network applications.
Im going to develop one android application which transfer music file, contact exchange, voice chat, text chat etc.. through WiFi. Which protocol will suit my application UDP or TCP. Because both protocol having some merits and demerits. Can u give me some suggestion, it will helpful for me..
Thanks in advance
If you don't know which is better for your application, then you should use TCP. When you get to understand TCP and its limitations better, then you may want to delve into the arcane world of UDP.
If one was the best (universally), the other wouldn't exist anymore...
If you want to make sure, that the data you send is really delivered correct to the client: use TCP.
If you're application is performance critical and/or bandwith is a limiting factor and the data packages are small (fit in one frame), use UDP.
In your case, I'd use TCP/IP, because for streaming or big data it is necessary that all frames arrive in the correct sequence (or can be ordered by the client).
TCP.
UDP does not provide reliable transfer, which sounds essential for the applications you describe. For example, if you're exchanging contact details and half a phone number isn't received on the other end - which is very possible with UDP, how would you recover from that?
TCP:
This protocol is the most commonly used, the reason for this is its reliability on packet delivery, as each packet is guaranteed to arrive at its destination. its more commonly used for things like streaming media, where you do not wish to have data last/
With TCP, its slightly slower than UDP and has more features:
Ordered data transfer - the destination host rearranges according to sequence number
Retransmission of lost packets - any cumulative stream not acknowledged is retransmitted
Error-free data transfer (The checksum in UDP is optional)
Flow control - limits the rate a sender transfers data to guarantee reliable delivery. The Receiver continually hints the sender on how much data can be received (controlled by the sliding window). When the receiving host's buffer fills, the next acknowledgment contains a 0 in the window size, to stop transfer and allow the data in the buffer to be processed.
Congestion control
Source # Wikipeida > Transmission Control Protocol -> Data transfer
TCP would be the most best choice to start of with as its the most comment and has a wider range of features
You should use TCP, since you want to make sure your packets actually arrive.
TCP has a little processing and bandwidth overhead but makes sure your packets really do arrive and resends those which have not been reported to be arrived.
UDP is most commonly used in scenarios where the arrival of all packets is not mission critical, e.g. if you update movement data in an action game like a 1st person shooter. But even then, I'd use TCP these days.
The application you are talking about has a large spectrum of requirements in terms of networking. You might want to consider using:
TCP: for the delay tolerant needs e.g. non-realtime file/message transfer
UDP: for delay intolerant needs e.g. voice
With TCP, retransmission is built-in that which you don't get with UDP. You don't want to be retransmitting voice packets (as example).
I am working on making RTSP url to work on Android.
I have used MediaPlayer and VideoView to play the RTSP url but both of them fail to play in G1 Device and emulator. Error is PVMFFailureiin PLAYER_INIT.
So I thought of implementing a RTSP client from scratch. I have developed a small application, it exchanges all the messages (DESCRIBE, SETUP, PLAY, TEARDOWN). But the problem is after PLAY, I should receive the RTP packets at client_port as mentioned in Transport header but TCP dump shows the following messages. I think UDP packets are coming but not received at the application.
11:38:50.213394 IP ew-in-f177.google.com.6970 > 192.168.1.2.6970: UDP, length 444
11:38:50.213451 IP 192.168.1.2 > ew-in-f177.google.com: ICMP 192.168.1.2 udp port 6970 unreachable, length 36
Please let me know how to solve this issue.
OpenCORE, the multimedia engine in Android, is rather stringent about sticking to various standards. Some things that may work in the wild (e.g., MP3 over RTSP) are not supported because they are not in the respective spec. Leastways, that's what we have been told.
Hence, it may be that the media you are trying to stream is slightly out of spec, or the server is slightly out of spec. You may wish to try to find some RTSP stream known to work on Android, get your player working right using it, then focus on getting it to consume your own streams.
Some handsets (I don't know whether Android falls in this category or not) include a firewall on the device. In order to receive packets you may have to perform a hole punch (i.e. send a dummy packet to the server. This will create an allow rule on a firewall running on the local device. It will also create the appropriate NAT mapping if necessary as well.)
Is the device on WIFI or on the carrier's network (which carrier)?