I'm using VpnService to capture packets and after capturing them I want to send them to their destination. Now, the capturing aspect works. I got the protocol, Source IP / Destination IP and the Source Port / Destination Port from the packets.
I was thinking about creating a socket with these parameters. VpnService has actually a method protect() which protects the socket and the traffic will not be forwarded through VPN.
I don't have muche experience with sockets. But the other day I read a comment here saying I only send the actual data through the socket and not the IP or TCP header? But since TCP uses a 3-way-handshake (correct me if i'm wrong) the first packets wouldn't have any data, just a SYN - flag.
Does that mean this method doesn't work or can i send a packet with the header through the socket?
Yes, we can send data via sockets and dont have to worry about Transport-layer or IP layer headers. Depending upon the socket type (SOCK_STREAM or SOCK_DGRAM), the underlying layer (and the stack for behavior) adds TCP or UDP header on top of application data. Lastly, before sending it out, the IP layer would add IP header. But, if your design requires, you can always "encapsulate" your entire packet with IP/TCP/Data as a data and send it to the other end. When the other end receives the packet, the application layer would receive data which would actually be the original IP/TCP/Data.
Edit
You should explore 2 more questions: a) how would we maintain the packet boundary and (b) what about MTU size. The first one needs to be thought about since TCP does not bother about packet boundary, so it is possible that when you read data on the receiver, it would not start with the header -- one quick solution would be to check if you are hitting the header and then read the length of the packet and continue to read till you have read that much data. The second one is if your packet is already the size of MTU, then adding 2 additional headers would throw it beyond MTU and hence, would likely be fragmented. If you are worried about performance, then this may not be a good thing.
Related
I am new to the BLE development. I want to send some large amount of data over a BLE connection with maximum throughput.
I have a GATT server, which is running on Linux, and a client which is running as an app on Android. I have created a custom characteristic with the maximum allowed size(512 bytes). I am requesting it from the app with a read operation. Every time I receive a call for reading on the server side I change it's value until I am finished with all the data(I know this isn't the best way but that's not the problem for now).
As for the connection parameters using android's requestConnectionPriority(CONNECTION_PRIORITY_HIGH) i can see that they are trying to negotiate a connection interval of 7.5ms but for some reason, it changes to 15ms and it remains there. Maybe my phone doesn't support it but I don't think so.
The next thing and the main problem is the MTU. Using hcidump, I can see that they are starting to negotiate the MTU as I can see an MTU Request from the client with a value of 517(by default) and a server Response with the same value. But when I trigger the data exchange I can see(using Wireshark) that the packets are containing only 32 bytes of payload. I don't know if it's a restriction with my Bluetooth adapter.
An MTU packet can consist of many radio packets and the 32byte radio packet payload is probably a restriction in your bluetooth adapter. No phone supports 7.5ms connection intervals at this point in time. You should also enable Data Length Extention if your phone and device supports it. This will allow you to transmit multiple MTUs throughout the connection event.
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 pretty new to TCP networking and would like to use TCP for real time transfer of data.
Essentially, I need my PC python to send data (single character) to Android application. Data to be send changes in real time, and upon change to data (usually about 0.5 - 1sec apart), it has to send this new data to Android app and will be displayed on the app immediately.
My question is
1) If I am using TCP, is it possible to keep the socket connection open even after sending one data to anticipate the subsequent transfers. Or do I need to close the connection after every single data transfer and set up another socket connection.
2) What is the latency of a TCP in the event I am performing something like these?
Any form of advice is greatly appreciated!
Most TCP implementations delay sending small buffers for a short period of time (~.2 seconds) hoping that more data will be presented before adding the expense of sending the TCP segment. You can use the TCP_NODELAY option to (mostly) eliminate that delay. There are several other factors that get in the way, such as where the stack happens to be in an ACK sequence, but its reasonably good way to get prompt delivery.
Latency depends on many factors including other traffic on the line and whether a given segment is dropped and needs to be retransmitted. I'm not sure what a solid number would be.
Sometimes real time data is "better never than late", making UDP datagrams a good option.
update: A TCP connection stays open until you close them with shutdown(), a client or server level socket timeout hits or the underlying stack finally gets bored and closes it. So normally you just connect and send data periodically over time. A common way to deal with a timed out socket is to reconnect if you hit a send error.
I'm writing an Android UDP client that connects to and communicates bidirectionally (with no relationship between sent and received messages) with a Windows server. Once the initial Datagram has been sent to the server I want to be able to send data in either direction at any time. My questions are:
1) Is it correct to keep the initial socket open and use it for both sending and receiving ?
2) Should I send and receive in the same thread (with a timeout on receive) or in separate threads (allowing the receive to block) ?
3) Will the socket automatically close if data is not sent / received within a certain interval ?
Yes, that is no problem and is the most convenient way to deal with the bidirectional communication. Also, if the client is placed behind a NAT, it is required for the hole punching to work correctly. Even though you bind to the same IP and port on the client, you are not guaranteed to get the same mapping in the NAT. Thus, the server might not be able to reach the client. Remember that these mappings time out and are initiated from inside the NAT'ed network, so some probing might be needed if the client is idle for a long time.
That is up to how you design the application, but there is no problem doing so. Just monitor both the read and write status of the socket using for example select. If you create a non-blocking socket combined with a read/write-queue, you are sure never to block operation. As UDP either writes everything or nothing, the queue's are quite straight-forward.
Based on my experience, that is vendor-specific on Android. Some phones keep sockets open for a long time, while others close them after a certain idle-period. All phones seem to close sockets when the device goes to sleep (the state when the power button is pressed), except those associated with a background task.
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).