4

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.

vector
  • 7,334
  • 8
  • 52
  • 80
fabregot
  • 43
  • 3

2 Answers2

1

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.

JSON
  • 1,819
  • 20
  • 27
-1

You might try out UDT: http://udt.sourceforge.net/

I have used it before with good success to communicate between Java and C++ processes.

Collin
  • 11,977
  • 2
  • 46
  • 60
  • Thanks. I'm going to take a look. I want to try with j-enet too (https://github.com/csm/java-enet.git). Anybody knows what versions of j-enet is compatible with C++ enet? – fabregot Sep 13 '12 at 22:17
  • UDT is nothing like enet. UDT is throughput oriented, and there's little reason to chose a UDP lib over TCP/IP if your looking for throughput. Additionally, UDT is only useful in limited circumstances because of it's CPU load. A single transfer (that is, a single client) will often consume over a quarter of the CPU (look it up). There's only two reasons to choose UDP over TCP, 1) latency, and 2) connection scope (TCP has a 1-to-1 connection model, where UDP can support all-to-all). Throughput oriented services are usually content oriented, which means they require little of both. – JSON Nov 10 '14 at 09:40
  • Don't get me wrong, UDT is awesome in it's own way (I remember reading something about it being used to transfer over 1 TB of maping data in less than an hour, still a record if I'm not mistaken) but that was at high CPU cost with poor latency and no need for peer-to-peer type behavior. Why choose UDP over TCP if your not looking for a scalable, low-latency solution, particularly with broader connection capabilities than TCP? – JSON Nov 10 '14 at 09:54