I'm developing an app that analyses the quality of your internet connection, and part of that is measuring packet loss.
I was thinking of sending packages to an IP address, but how can I send messages and check that they return? I'm guessing I need to send a package prompting a reply, but I can't find an example of that using either search or Google.
Or should I use existing traffic(how?)?
Besides that, how do I measure round trip time?
As TCP is reliable transport, you don't see dropped packets. In Linux you can use ifconfig to see how many retransmits you incurred. I am not sure what command line tools would show you this on Android, but you would need to use a system tools to give you this information.
BTW You can estimate the packet loss using UDP packets.The packets loss rate for UDP and TCP is not the same but it gives you an idea.
You'll need to use UDP, or ICMP (ping) for this as you won't be able to see TCP packet loss easily.
If you use ICMP you'll need to ensure the opposite computer responds to ICMP. Firewalls often block ICMP.
If you use UDP the other computer will need server software which can recognize your packets and reply as quickly as possible. The simpliest type of server for this would be called an Echo Server.
Here's a Java UDP Echo Server
Round trip time can be measured by taking the difference between the time you transmit a packet to the time you receive a reply for that transmission. Your protocol should be trivial so as not to pollute roundtrip time with processing time.
Related
So as part of a project I'm working on, I am wanting to monitor inbound and outbound packets through a specific port on a single host/device. The program will run in the background and send data to a server where it will eventually be parsed.
I am not wanting to send/receive my own packets but rather monitor the inbound and outbound packets for any anomalies known with TCP, such as a TCP/SYN flood.
I was taking a look around at what might be useful to me, but I am stuck on what would be the best to use to do this as well as how I would start going about this.
What I have found is: JNetPcap and Pcap4J
All help is undeniably appreciated!
my task is to receive UDP packets on an Google Compute Engine. Given is the port, which is 300 and I already have a simple Java program which can handle these UDP packets.
My problem now. Get the UDP packets to my Java program.
For that I don't know how to do this.
What I have tried so far ist to let the Java program direct listen to the port, which didn't work. I suspect the traffic from outside the GCE must be routed to the inside?
First make sure you've added a firewall rule on your GCE VM instance's network which allows incoming traffic for UDP protocol on port 300.
You can do this by going to the Developers Console, select your project, then Compute-> Compute Engine-> Networks, click on the right network and verify firewall rules (and tags as well if you used them). If the rule is not added, then add a rule for the traffic.
"gcloud" is a command-line tool which you can use it to list and verify your firewall rules as well [1]:
$ gcloud compute firewall-rules list
If the firewall rules are good, then use a simple troubleshooting tool like netcat to test if traffic is being forwarded to your VM instance.
1. Listing Google Compute Engine firewall rules
I recommend not using Java to process UDP. I experienced inexplicable short periods where all UDP traffic arriving was being lost. This was caused by garbage collection.
The architecture that works for me is to use a GCE VM with a C++ app receiving UDP data, then using libCURL, convert the data to HTTP and dispatch it to Google App Engine for processing. To make the UDP receiver scalable and tolerant, use network balancing and multiple VMs listening for UDP.
I'm working on a project for class using Java and UDP senders and receivers. The premise of the problem is to read in a text file, store the contents within a packet, send the packet, receive the packet, and read out the file on screen and create a new text document on the receiving computer of an identical text file.
I have all of that working. When I test with a local host it appears to work 100% of the time. When I send it from my laptop to my PC it appears to work 100% of the time. However, when I send it from my PC to my laptop it does not work.
I have several System.out debug statements to verify some of the information I send. I know that the text file should take 7 packets. However, whenever I send it from my PC to my laptop it says that I am sending 46 packets.
My initial thought is that maybe the packets are being sent out of order. The first packet I am sending indicates how many packets the receiver should be expecting to receive. I thought maybe for some reason the "46" could indicate a capital "F" so I removed all the capital "F" and it still says I'm sending 46 packets.
I thought maybe I was sending too much information at once so I used Thread.sleep() to give my receiver time to keep up -- that did not work either.
Finally, I read through the Oracle Documentation and some posts online and found out that UDP is unreliable. So, I'm assuming it could potentially be that. However, I want to just verify that that could be the issue.
Or if anyone has a better idea as to what could be causing the problem that would be awesome as well!
Thanks for your help :)
Yes, UDP is an unreliable protocol. UDP messages may be lost, and neither the sender or receiver will get any notification.
The 7 packets becomes 46 packets is typically due to fragmentation at the IP packet level. The protocol level beneath IP (e.g. physical ethernet packets, wifi packets etc) typically has a hard limit on the largest IP packet that can be sent "in one go", and similar limits are imposed by network routers, gateways and so on. If an IP packet that is larger than the limit is sent, two things can happen:
The IP packet may turned into "fragments" that need to be reassembled by the receiver.
The intermediate equipment can sent an ICMP message back to the sender telling it to send smaller IP packets.
In either case, the net result is that the number of IP packets needed to send a given sized UDP message can vary, depending on the network.
Of course, if a UDP message needs to be sent as multiple IP packets, AND there is local congestion in the network, that will increase the likelihood of packets, and hence messages failing.
But the bottom line is that UDP is not reliable. If you want reliability, the simple solution is to use TCP instead.
As I am programming a network chat (java, but should not make a difference for the question), and wanted to use UDP, I ran into the problem of it not working over the internet. After a little research I found out that you have to have port forwarding for the specific port activated. So now it comes to my question:
Does UDP work over the Internet in a not configurable way?
For example, if I would program a whole Network Game would it make sense to use UDP? Or would I require the Player to activate Portforwarding and open the Port etc?
When would it make sense to use UDP then? And why?
I'm actually not understanding the whole point of UDP then.
For my programming point of view I would like to have a way to use it intuitive.
Like creating the DatagramSocket and the DatagramPacket, configure the Packet with the Data and the Destination and send it away over the internet.
As for my Users I don't want them to have to configure any specific things like opening the exact port they want to use etc. I just want them to use the program (server and client) and it should work.
The problem you've run into is not one of UDP vs TCP (although using the unreliable, unordered UDP as the basis of a chat application seems like an odd choice to me).
The problem is that of NAT traversal. In a nutshell, home routers perform a network function called NAT - Network Address Translation. They do it in order to use a single public IP address for all machines inside the NAT (which are given private addresses - usually 10.0.0.0 or 192.168.0.0). The router then switches the source IP address in all packets sent from inside the LAN from the private address to the public one. It uses port numbers to "remember" which machine sent what to what address, in order to perform the backwards translation when the response arrives.
The problem arises when someone wants to initiate a connection to a machine behind a NAT. Without seeing an outgoing connection first, the NAT doesn't know to which internal computer and port it should forward the packet. This is what happens to you.
There are various fixes for this issue, with the simplest one being manual port forwarding (as you've discovered), but it's a well known problem faced by any peer-to-peer application. If you need to contact a machine behind NAT (i.e. contact most home users) and you want your application to work out-of-the box (without your users fiddling with their routers) you need to research NAT traversal techniques, implement them in your application, and hope that the user's home routers support them. It's a huge pain in the neck.
EDITED: with Joachim Pileborg's correct suggestions!
UDP is often a better choice for action-based games, where it's vitally important to have updates to the client or server with the latest data about a player, player input, or the game world.
TCP begins with a 3-way handshake to establish a connection (which takes time). If your game communication protocol is via TCP, all packets in a message have to arrive before the message becomes available. Even a small amount of Internet congestion could cause your game to lag.
TCP is good for communications that MUST arrive in full.
With UDP, the client or server can send the latest player/game state in individual packets that do not depend on arriving in order. If a packet is late, or arrives out of order... it should be ignored.
UDP is good for communications that need to be fast, but losing individual packets is OK.
Both should be available in your Java platform.
Here's some further reading:
http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
I need to implement client/server instant messenger using pure sockets in Java lang.
The server should serve large number of clients and I need to decide which sockets should I use - TCP or UDP.
Thanks, Costa.
TCP
Reason:
TCP: "There is absolute guarantee that the data transferred remains intact and arrives in the same order in which it was sent."
UDP: "There is no guarantee that the messages or packets sent would reach at all."
Learn more at: http://www.diffen.com/difference/TCP_vs_UDP
Would you want your chat message possibly lost?
Edit: I missed the part about "large chat program". I think because of the nature of the chat program it needs to be a TCP server, I cannot imagine the actual text content sent by users over a UDP protocol.
The max limit for TCP servers is 65536 connections at the same time. If you really need to go past that number you could create a dispatcher server that would send incoming connects to the appropriate server depending on current server loads.
You could use both. Use TCP for exchanging the actual messages, (so no data lost and streaming large messages, (eg. containing jpegs etc), is possible. Use UDP only for sending short 'connectNow' messages to clients for which there are messages queued. The clients could have states like (NotLoggedIn, TCPconnected, TCPdisconnected, LoggedOut) with various timeouts to control the state transitions as well as the normal message-exchange events. The UDP 'connectNow' message would instruct clients in 'TCPdisconnected' to connect and so move to 'TCPconnected', where they would stay, exchanging messages, until some inactivity timer instructs the client to disconnect for now. This would, of course, be unreliable and so you may wish to repeat the 'connectNow' message every X seconds for N times until the client connects. The client should, in any case, attempt a poll every X minutes, just in case...
It depends whether the user needs to know if the messages have been delivered to the server. UDP packets have no inherent acknowledgement. If the client sends an IM message to the server and it gets lost in transit, neither the client or the server will know about it.
(The short answer is "use TCP" ... but it is worth thinking through the design implications for yourself.)
TCP would give you reliability, which is certainly desirable when during instant messaging -- you would not want messages to be dropped during converstation.
However, if you intend on using group messaging, then you might end up using mulitcast. For such cases, UDP would be the right chioce since UDP can handle point to multipoint. Using TCP for multicast applications would be hard since now the sender would have to keep track of retransmissions/sending rate for multiple receivers. One alternative could be to use TCP for point-to-point chat and use UDP for group messaging.