I'm going to develop a little Android game with multiplayer feature. I've made a server framework in C++ using eNet library and I would like to use this framework for make the server.
So, there is any networking library like eNet compatible with Java and C++? I know that exist jEnet (but is very out of date Java-enet-wrapper (https://github.com/csm/java-enet-wrapper), it's immature.
Check out https://github.com/julienr/libenet-android.
ENet is much more advisable than UDT in your case as UDT can be processor intensive and a gaming service would at least hope for many connections. The difference is from UDTs implementation of congestion control which has relatively high CPU demand. UDT is awesome, but designed more for large, high bandwith transfers over long distances, rather than small, high latency transactions which are desired in gaming.
Also note that main stream congestion control algorithms do not do well with small transactions. They work by monitoring RTT of each packet in a transaction and/or by monitoring packet loss rate within a transaction, which is moot when each transation is only 1 - 2 packets on avg. The additional demands of the congestion control protocol will effect latency even though the congestion control itself is not likely to ever be engaged if transfers are kept small.
You might try out UDT: http://udt.sourceforge.net/
I have used it before with good success to communicate between Java and C++ processes.
Related
Server Environment
Linux/RedHat
6 cores
Java 7/8
About application :
We are working on developing a low latency (7-8 ms) high speed trading platform using Java. Multi-leg orders are sent after algo conditions are met
Problem
The orders to the exchange using TCP/IP java.net.Socket APIs (using java.io.OutputStream.write(bytes[] arg0) ). Profiler measurement is records as 5-7 microsec which is very high as per our low latency reqs. We are not made use of setPerformancePreferences() api as suggested in one of the questions posted in stacktrace.
Question
Any alternatives to java.net.Socket to reduce the socket
transmission time?
Any optimization techniques to improve performance
Is setPerformancePreferences() is of any use?
We are not made use of setPerformancePreferences() api
It doesn't do anything and never has. I wouldn't worry about it.
Any alternatives to java.net.Socket to reduce the socket transmission time?
The problem is most certainly not a software one. You can get <8 micro-seconds from Java to Java on different machines, but you need low latency network cards like Solarflare or Mellanox.
If you want fast processing you should consider either a high GHz haswell processor, possibly over clocked to 4.2 or 4.5 GHz or a dual socket Haswell Xeon. The cost of these compared to the cost of trading is not high.
Any optimization techniques to improve performance
Using non-blocking NIO i.e. ByteBuffers and busy waiting on the socket connections. (I wouldn't use Selectors as they add quite a bit of overhead) I would turn off nagle.
For some micro-tuning, use an affinity bound thread on an isolated cpu.
Is setPerformancePreferences() is of any use?
Looking at the source .. I will let you be the judge.
public void setPerformancePreferences(int connectionTime,
int latency,
int bandwidth)
{
/* Not implemented yet */
}
Java 7/8
In term of which version to use, I would start with Java 8 as it has much improved escape analysis which can reduce garbage of short lived objects and thus help reduce latency between GCs and jitter from GCs.
A couple of things come to mind:
JNI: JNI lets you write C code that is ran from your Java code. Critical parts of your Java code that are running to slow can be migrated to C/C++ for improved performance. Work would be needed to first identify what those critical points are and if its worth the effort to move it to C/C++.
Java Unsafe: Wanna get dangerous? Use Java Unsafe to bypass that pesky GC. Here is more info on it. On Github you may find some cool wrapper code to more-safely use Java Unsafe. Here is one. More info.
LMAX Disruptor: Read more about it here. This company is also building a fast trading system in Java. Disruptor allows for faster inter-thread communication.
Bytecode scrutinization: Review your code by looking at the byte code. I have done this for a video game I made and was able to streamline the code. You'll need a good tool for turning your class files into readable bytecode. THis might be the tool i used.
Improved garbage collection: Have you tried using the G1 garbage collector? Or messing around with the older GC's?
Highscalability: This site is full of good info on making code fast. Here is an example that might help.
New API I dont know exactly how to use New API, but it has come up in articles I have read. Here is another article on it. You might need to use it via JNI.
I have a basic Java Messaging application that sends JAVA objects to a remote server for processing. I leverage Spring support on both sides of the wire and use ActiveMQ as my JMS provider. It works well - and we have experienced no real problems with 10 clients that send messages concurrently.
However, we now really want to scale. The number of clients is likely to increase to circa 500 . Also, the bandwidth used for each client is more of an issue than was declared initially.
I was wondering whether anyone thought that ActiveMQ is the right tool for this job - or whether socket based TCP/UDP would help us scale better. We are not well versed in some of the 'advanced' features of AMQ, since we are using it with basic Spring JMS Template support.
Any comments / thoughts would be appreciated.
Thanks
Without knowing what quality of service and SLA's you're trying to achieve, the basic rules I follow when evaluating messaging service implementations for any application are the following...
Performance over Reliability
Fast messaging
Intermittent message loss acceptable
Messages are non-persistent
Little to no cost
In this case, a product like ZeroMq (and others alike) would suffice since it works at the socket level, is decentralized, offers extremely low latency and scales well in large distributed systems, and is open source so cost is negligible. If some use cases require persistence and reliability, be prepared to implement custom solutions that traditional messaging middleware offer out-of-box (persistence, durability, replication, etc).
Balance Performance and Reliability
Performance and reliability equally important
Lost messages not acceptable
Messages are persistent
Need for some support
Relatively low cost
Here's where products like ActiveMQ, RabbitMq, etc., come into play. Broker-based middleware addresses reliability and persistence concerns while providing good performance and scalability. Support costs are usually low enough for small and mid-sized companies to afford without breaking the bank. It's safe to say most messaging needs fall into this category because it provides accessibility to both performance and reliability, and you can sacrifice one for the other based on future needs as your application matures without swapping out the entire messaging infrastructure due to a bad choice made years earlier.
Reliability over Performance
Reliability is most important
Messages can't be dropped
Message redelivery out-of-box
Clustering, HA, replication, etc. available out-of-box.
Need enterprise-class, global support and professional services
High Cost
Financial firms, trading systems, banking applications, etc., typically have such requirements where message system reliability has a dollar-value attached to it, and when things don't work, money is lost. Therefore, message persistence, HA/fault-tolerance, fail-over, are all extremely important. If cost is not an issue, look at products like WebLogic, Websphere, SonicMQ, or TIBCO, etc.,...they're expensive, but all offer solid reliability, enterprise support and perform well under load. I've used SonicMQ, it's a great product, very fast and reliable, but it costs an arm and a leg.
Hope it helps...
I have a Java application that require communication between different process. Process could run in same JVM or different JVM, but runs on the same machine.
My application need to submit "messages" to another process (same or different JVM) and forgot about it. similar to messaging queue like IBM "MQ", but simple, and only use memory, no IO to hard disk for performance gains.
I'm not sure what is the best approach from Performance prescriptive.
I wonder if RMI is efficient in terms of Performance, I think it require some overhead.
What about TCP/IP socket using local host?
any other thought?
I wonder if RMI is efficient in terms of Performance, I think it require some overhead.
RMI is efficient for what it does. It does much more than most people need, but is usually more than faster enough. You should be able to get of the order of 1-3 K messages per second with a latency around 1 milli-second.
What about TCP/IP socket using local host?
That is always an option but with plain Java Serialization this will not be a lot faster than using RMI. How you do the serialization and deserialization is critical for high performance.
An important note is that much of the time is spent serializing and deserilizing the message, something most transports don't help you with, so if you want maximum performance you have to consider an efficient marshalling strategy. Most transport protocols only benchmark raw bytes.
Ironically if you are willing to use disk, it can be faster than TCP or UDP (like ZeroMQ) plus you get persistence for "free".
This library (I am the author) can perform millions of messages per second between processes with latency as low as 100 nano-second (350x lower than ZeroMQ) https://github.com/peter-lawrey/Java-Chronicle Advantages are
ultra fast serialization and deserialization, something most transport benchmarks avoid including this as it often takes much longer than the transport costs.
is that you can monitor what is happening between queues any time after the message was sent.
replay all messages.
the producer can be any amount of data ahead of your consumer to handle micro-burst gracefully up to the size of your disk space. e.g. the consumer can be TBs behind.
supports replication over TCP.
restart of either the consumer or producer is largely transparent.
If you are developing server application try to consider ZeroMQ. It has great performance, allow to build interprocess communication easier, allow to build asynchronous API.
ZeroMQ declare fantastic performance with InterProcess communication. Even better than TCP sounds great. We are consider this solution for our clusterisation schema.
Pieter Hintjens give the great answer for performance comparison between different Message Broker.
Please suggest java library, that implements reliable udp. It will be used for a game server to communicate to clients and to other servers.
PS Maybe you can suggest tech that will be more productive to work with for such task(game server)? But this must work on linux.
Edit: It's an action type game, so it needs to talk to server as fast as possible.
Edit 2: I found Enet which was used for a FPS game, but it's C++, will there be an overhead if I call it many times a second?
These are the libraries/frameworks I know of that implement something like reliable UDP:
Mobile Reliable UDP (MR-UDP)
MR-UDP aims at providing reliable communication based on UDP from/to mobile nodes (MNs), with least possible overhead. It extends a Reliable UDP (R-UDP) protocol with mobility-tolerating features, such as the ability to handle intermit-tent connectivity, Firewall/NAT traversal and robustness to switching of IP addresses or network interfaces (e.g. Cellular to WiFi, and vice-versa).
UDT-Java
Java implementation of UDP-based Data Transfer (UDT)
UDT is a reliable UDP based application level data transport protocol for distributed data intensive applications over wide area high-speed networks. UDT uses UDP to transfer bulk data with its own reliability control and congestion control mechanisms. The new protocol can transfer data at a much higher speed than TCP does. UDT is also a highly configurable framework that can accommodate various congestion control algorithms.
JNetRobust
Fast, reliable & non-intrusive message-oriented virtual network protocol for the JVM 1.6+.
It resides between the transport and the application layer.
Characteristics:
reliability of transmitted data
received, unvalidated data is available immediately
the package is bigger than UDP's package, but smaller than TCP's package
no flow control
no congestion control
Disclaimer: I'm the author of JNetRobust, it's new and still in alpha.
There is an java implementation of RUDP (Reliable UDP) protocol (RFC908, RFC1151)
http://sourceforge.net/projects/rudp/?source=dlp
You may find you don't need reliable messaging for all message types. For example, if you are repeatedly sending the status of things like players, and a few packets are lost it may not even matter.
There are reliable high performance UDP based libraries which support Java. One of these is 29West's LBM. It is not cheaper because it is very hard to get this right. Even with a professional product you may need a dedicated network for UDP to minimize loss.
For the purpose of a game I suggest you use a JMS service like ActiveMQ which runs wherever you can run Java. You should be able send 10K messages per second with a few milli-seconds latency.
When people say something must be as fast as possible, this can mean just about anything. For some people this means 10 ms, 1 ms, 100 us, 10 us, 1 us is acceptable. Some network routers support passing packets with a 600 ns latency. The lower the latency the greater the cost and the greater the impact on the design. Assuming you need more speed than you need can impact the design and cost unnecessarily.
You have to be realistic seeing that you have a human interface. A human cannot respond faster than about 1/20 of a second or about 50 ms. If you keep the messaging to less than 5 ms, a human will not be able to tell the difference.
Libjitsi has SCTP over UDP, which breaks everything up into packets like UDP but guarantees reliable delivery, like TCP. See https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/sctp4j/Sctp.java
UDP is by definition not a reliable service. It does not guarantee a high quality of service. You can, however, use TCP.
I'm pretty new to web programming and I'm currently developing a web back end for a mobile application. Currently I have the users log in using servlet interactions and once they have full access to the application I need to open a Socket Connection so that I can provide server pushes. Now the problem I'm running into is how people handle thousands of concurrent socket connections. I've run into people talking about ThreadPools which seems pretty easy to implement and NIO. Is there some framework that I can work with to ensure my servers are handling at least 20-30k concurrent connections. I could also forget TCP connections and go for Long-polling but from my understanding TCP is best option resource wise.
#Steve - I'm looking at the former: One serversocket with thousands of connections.
I would look into clustering the web end immediately and use that as your primary scaling mechanism. 30k connections is quite a lot and you don't have much room for growth before you hit a server limit of some kind. If the I/O itself isn't onerous I would just use lots of threads and servers with lots of horsepower and memory. Get it working that way so you can ship, and have a fallback plan to switch to multiplexed NIO if performance or scaling becomes a problem, but be warned that it's a radical overhaul and about ten times as complex to program as java.net. After several years' consideration I am more and more wondering whether NIO to economize on threads is really worth it: it adds several new problems of its own such as a need for push parsing; synchronization issues with the selector if there are worker threads that need to change the registration state of channels; lots of ways to get the code wrong; and the fact that the scheduling overhead moves out of the OS into your application, where you only have linear set-iterator data structures to deal with it unless you engage in yet another level of complexity. It's worth remembering that select() was invented for Unix to allow economizing on processes, which are expensive. Threads are pretty cheap really, and provide a very simple programming model with built-in context for handling a single connection. NIO barely manages this at all except via disciplined use of selection key attachments, much less naturally.