(I did search prior to asking, but I could only find fastest Java IPC techniques)
What is the fastest way in Java to send a packet between two computers in Java (connected by one ethernet cable), on Windows and Linux (if the answer varies per OS)?
I have guessed UDP would be faster than TCP (due to TCP's three-way handshake scheme), but are there any other considerations which need to be made?
Are we limited to sockets (Unix-specifc answer?) or are there alternatives? What technologies can be used to send/receive the UDP as fast as possible?
Likewise, are there particular high-performing ways to receive and read the data sent from another computer?
Well, there's not much between TCP/UDP if you ignore the connect/disconnect latency. If your protocol can keep a TCP conection up and disable inappropriate, latency-inducing optimizations like the Nagle algorithm, I don't see why TCP should be struck off as a solution, though there is the slight complication of requiring a protocol on-top to exchange any message larger than one byte.
Most network rate and latency performance are usually limited by phy and route constraints anyway. Looking at one packet between two peers, it doesn't matter too much what IP protocol you use since the dodgy routers, c-limited satellite links, congested fibers, noisy and retransmit-ridden microwave/wifi/3G links, and rubbish last-mile copper will stuff you up anyway.
The answer is via courier pigeon. Other alternatives include sneakernet and autonet. I prefer bicyclenet.
Related
While looking for ICE/STUN libraries for a peer-to-peer Java application, I ran into a problem. I needed to be able to ensure reliable delivery. All Java ICE libraries that I could find offered UDP hole punching (via the STUN protocol), but not TCP hole punching. I want peers to be able to reliably send files to one another over a network without needing a server, but UDP is not reliable. How do I get reliable, cross platform, peer-to-peer data delivery?
I have done a little research and have found this solution, know as "pseudo-TCP" - for example:
http://nice.freedesktop.org/libnice/libnice-Pseudo-TCP-Socket.html
Pseudo-TCP is reliable and also available in Java,
See:
https://github.com/opentelecoms-org/ice4j/blob/master/test/test/IcePseudoTcp.java
(^ from the ICE4J library^)
And also:
https://code.google.com/p/ice4j/source/browse/trunk/src/org/ice4j/pseudotcp/PseudoTcpSocket.java?r=335
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 have java server-client application using CORBA connection. the application running well with wired connection, but when connected via WiFi the client app running very slowly. Anybody has an idea why CORBA very slow over WiFi?
thanks in advance.
You haven't quantified at all what is slow and fast. There are a few things to look at, first the design of your IDL interfaces. Normally each invocation of an IDL operation results in a remote call which goes over the network. For example when you want to retrieve 1M values, don't perform 1M operations, but retrieve them in bigger chunks. Secondly, what is the payload of the invocation, what is the size of the data to transmit. If that is large and your wifi link is slow, than it just takes time to transmit the data, ZIOP (CORBA Compression) adds the ability to CORBA that it will compress your application data, something to look at. Last, is your network setup correctly, do all host names and ip addresses you use do work correctly, if for example in your wifi setup the DNS settings are not ok, than reverse lookups can kill performance.
Check your CORBA implementation to enable logging, see what is happening, how much data is transmitted, do you see errors, etc.
CORBA can be a very network intensive protocol if developers design CORBA objects like ordinary C++/Java Objects, this will cause several small interactions over the network. This makes it very susceptible to network latency. I.E. not the overall speed of the network but the time it takes to open a stream and send a single packet. Wireless networks can be very fast sending large packets once a connection is established, but, I suspect your wireless network is quite slow to route packets.
I am wondering if it is a good idea to have 2 separate ports one for read, one for write ? Can I expect better performance ?
NOTE: Server is Centos, Client is flash, message format in communication is JSON.
There's no significant performance advantage, and it can require much more code to handle two sockets than one, particularly on the server side.
You'd also still have to open both sockets from the client side, as most systems wouldn't permit the server to open a connection back to the client.
AFAIK, TCP is optimised assuming you will send a request and get a response on the same socket, however the difference is likely to be trivial.
Often the simplest solution is also the fastest.
What is the problem you are trying to solve?
Best to have it in TCP with a single port, also depending if you are using NIO or not,
Just in case you want to have 2 ports & Unless its not a TCP (eg UDP)
If you are in Cent OS 32 bit, ensure that your kernel to use up more ports that it should.
This is to prevent port starvation & would quickly cripple your server.
Do the math, if you need to support 100 users, 100 x 2 = 200 open ports.
but in most cases, its only (65534 - 1024) ports available, so, if you could afford it, then its cool.
Also remember that most ISP's would block certain ports, so keep the right ports open for read / write.
regards
The point of my question is to ask if it is accepted to use both TCP and UDP to communicate between client and server.
I am making a real-time client server game with parts of the communication that need to be guaranteed (logging in, etc..), but other parts will be ok to lose packets (state updates, etc). So, I would like to use UDP for most of the data communication but I do not want to have to implement my own framework to insure that my control communication (logging in) is guaranteed.
So, would it be reasonable to initially use TCP to manage a connection, and then on a separate port send data communication pack and forth?
You should absolutely do it that way (use TCP and UDP to accomplish different communication tasks.) And you don't even have to use two different ports. One will suffice. You can listen to the two different protocols on the same port.
It is quite reasonable and already used in mainstream. Even when browsing the Web, DNS operations are UDP-based and HTTP connections are TCP-based.
Keep in mind that you should either consider the two connection types to be completely independent or employ additional measures to properly handle any inter-dependencies. TCP connections can have timing issues at the OS and network levels and UDP connections have packet loss issues. You should take specific measures to avoid deadlocks and performance problems when the TCP part of your application stalls or a UDP packet is lost.
It is not only accepted but is widely used. As a good example, BATS Exchange is using this approach in their market data distribution system, to implement a recovery mechanisms.