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).
Related
I have to exchange data between two bluetooth devices, one of them will be an Android device. For simplicity's sake you can assume the other device will be a generic linux device running bluez producing data similar to the data a fitness tracker would produce.
The scenario seems a straightforward use case for Bluetooth Low Energy. The problem i am currently running into comes from the fact that communication has to be reliable (reliable in the way TCP is reliable). This means:
no losses
no corruption of data
order needs to be preserved
no duplicates
no phantom packets
While losses are prevented at link layer level, the order for instance seems not to be explicitly preserved when working with Low Energy (using indications would probably achieve this).
Not having done a lot of work with Bluetooth I am currently overwhelmed quite a bit with the amount of options while at the same time no option seems to fit the bill nicely.
Is there a "best-practice" for setting up reliable communication between two bluetooth devices? A Bluetooth Low Energy solution would be preferable, but is not mandatory.
Once your Bluetooth connection is setup its reliable. So you don't have to be worried about data loss or corruption.
So the things you're worried about can be easily handled in your side. You'll get proper connection and disconnection callback while setting up a BroadcastReceiver for your BluetoothAdapter.
In case of any disconnection you may have to restart the procedure for connection again and once its established properly you may resend the data.
I don't know about your purpose yet, but one thing I need to mention here is, I would not recommend Bluetooth communication if you're holding the connection for long time. Some devices disconnects the connection automatically after some time if there's no continuos transmission.
Android has Bluetooth support, but it only allow to send ot receive data from stream. There is a very good sample project from Google: https://github.com/googlesamples/android-BluetoothChat . The only drawback of this sample is that it use Handler to nitify about Bluetooth events. I changed it a bit so it use another Thread and from it calls methods of interface you set, take a look at project: https://github.com/AlexShutov/LEDLights . This is ordinary Bluetooth, not BLE, hope it will help
Android's BLE stack is as good as the link layer specification. So you can use "write without response" in one direction and notifications for the other direction. Just make sure your peripheral side does not drop incoming writes.
BLE uses 24-bit CRC. for the amount of data transmitted using BLE the CRC is quite robust and the possibility of corruption is very low ( note that TCP CRC is 16bit and the Ethernet CRC is 32bit, please see http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html).
The ordering issues in wired network is a result of routing packets through different routes to the same destination ( plese see If TCP is connection oriented why do packets follow different paths?) . This is partially due to the use of sliding window acknowledgement protocol, which allows a number of packets to be transmitted before being acknowledged.In BLE there is no routing and the acknowledgement scheme is a variation of stop and wait ARQ scheme(2-bit lazy acknowledgement), this means that it is not possible to send a new packet without being acknowledged. These two factors makes the possibility of having an out of order transmission highly unlikely.
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.
Something is troubling me for years.
I work with a lot of bluetooth and lately wifi streams (spp). Those streams always connect to specific devices and communication happens via simple byte commands.
Some of the devices (their microcontrollers) i program myself and there i have to always check if the signal on the wire is what i expect, send and check for crcs.
Somehow i want to do the same on my smartphone because i access my streams with "readByte" and read byte by byte and i am always wondering if it is actually possible that
a) one byte from a message can be missing
b) messages arrive mixed or "out of sequence"
I have no idea how much the underlying hardware does. Does it check every message with crc and requests the message again if it was corrupted ? Or does it blindly pass every byte through to my "readByte" method ?
If the device sends message a and then b, is it possible that the receiver receives b before a and passes my code b before a or even mix up the bytes like a zipper and give me a[0] then b[0] then a[1] and so on.
How much trust in those streams should i have ? Some clarification would be appreciated
I think you can sleep well. WiFi and Bluetooth based on packet switch network, each packet comes with crc, and physical layer has built-in congestion and link quality control - so, aside from ultra rare firmware bugs, it is actually more reliable than wired serial connection.
In other words - error correction occurs at lower level than you are using..
Answer to question about packet arrival order: point to point protocols aren't affected by this problem. Packet reordering occurs when they travel by different routes, thus no problem when there are no other routes.
You will get same bytes in same order if you are using byte oriented streams over those protocols, because they are designed with this goal in mind. Packet access, on the other hand, is not, but Android doesn't provide you means to use it.
I feel like If you ever learnt about Computer Network OSI Model, you will understand what I am talking about better.
First, TCP/IP has nothing in common with Bluetooth. TCP is a transport level protocol whereas Bluetooth would be a lower level protocol. Thus you could use TCP or UDP on top of Bluetooth just as you use TCP and UDP on top of Ethernet.
Second, When data transferred through bluetooth devices, TCP protocol would be used. The TCP use congestion recovery algorithms to ensure data is transferred exactly. Modern implementations of TCP include four intertwined algorithms for flow control: slow start, congestion avoidance, fast retransmit, and fast recovery. So, If you want to know more about this, you may search the internet. Because they would rather be more theoretical than programmatic.
Well of data corruption i don't have any good idea.
But "mix up the bytes like a zipper and give me a[0] then b[0] then a[1] " should not happen.
I built app that parses nmea messages form external bluetooth gps. I don't check anything and some how my app works stable.
I want to know if there is any way to communicate users without internet connection to a server.
I thought it might be possible through SMS and machine-readable encoding. However this question confirms that iOS apps allows sending but not reading SMS: iphone app reading sms
I've also read a lot about using USSD but it seems that mobile opened messages aren't possible in iOS (dial USSD code from iphone programatically) and while in Android is possible to call a code programatically there is no USSD API to, nor it's possible to send USSD messages silently.
Is there any way to transfer data between my app and my server with only basic voice-sms signal?
You are correct that SMS could be used to communicate with the server, if the server has access to a GSM modem. For large volumes of SMSes, you'd expect to have an internet connection between your server and an SMS gateway that connects directly to the messaging centre in the mobile network, instead of a modem.
This is the model of the SMS voting servers.
You can send/receive SMS as long as you have a GSM network, and you're right; no IP connection is needed.
The Android platform lets you send and receive SMSes - see here.
Disadvantages are that SMS can be expensive, and has no guaranteed delivery, and no guaranteed delivery time. It's not suitable for real time communication.
USSD is another form of communication between a mobile device and the network that's built directly into the GSM network, but USSD messages are owned or licenced by the network operators, and aren't free for customers to use, as SMS is.
EDIT: USSD isn't a native protocol in CDMA, but various implementations are available from different operators. For example, here's a patent application describing an idea for one such system, which does not appear to require an IP connection. Googling "USSD CDMA" also gives various news items about commercial implementations, technical details unknown. I think you just have to find out what your target operator(s) offer.
I haven't worked directly with WAP, but a glance at the WAP Protocol Stack shows that it can indeed run over CDMA, or GSM without an IP connection. There is also a very useful Wikipedia article. My experience testing MMS is that it usually doesn't work without an IP connection, even though it is supposed to (according to that Wiki article, with WAP/SMS). So I would question how far European operators or mobile devices are supporting or testing WAP. Whether WAP is a practical choice could come down to pricing/availability at the end of the day, rather than technical issues.
Well, there are yet other options, depending on the amount of data you need to transfer back and forth to the server.
Instead of sms, for short amount of data you could try to implement an Asterisk PBX, whith your mobile calling your server and then sending other DTMF digits as your data, which would be interpreted by your Asterisk PBX (like an interactive phone audio menu from your cable company). Asterisk is GPL open-source.
Another option (an expensive one and with heavy work to do), would be to generate an audio signal encoded with your data content, and dial a phone number linked with an attached fax/modem pci board on a server, sending that audio like a call. It would'nt need to be a long call, as you could fit lots of data in a short bursts of audio stream.
Your server could check that data by acessing the content on the receiving end. Simply recording the call from the attached fax/modem pci board, or you could use an Asterisk PBX server on a local computer to save the audio file and then process by your server software.
Anyway, you would need to create a new protocol and data encoding type, like you mentioned "machine-readable encoding".
So, for the data types you could just save a lot of short audio files on your mobile and play them as your datatypes, but it would be easier to just go for the DTMF already mentioned above. Or you could encode like this: get the sound spectrum allowed to use through the voice call (Wideband/Narrowband), and divide it by the amount of single characters or chunks needed (take a look at how to encode in base64, to have some ideas). Then create a function to just encode your data as a short audio stream (read about PCM encoding and also read more about Fast Fourier transforms, if you want to complicate (but speed up) even further.
Create a simple protocol like this: first audio packet is a sequence of tones that makes a request, authenticates, and waits for acknowledgement response from the server (which could be just by not dropping the call 1 second after that). The 2nd audio packet is the size of the first frame of data, then the 3d audio packet onwards is the data itself with the size shown before. And so on. Have a look at the ftp protocol description for simplicity. Then you need to refine it so that the time of every packet above is the least possible while mantaining confiability.
For costs saving on voice calling, you could also explore phone number options, like Google Voice, Skype or any Voip service.
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.