I am about to write a client-server application (a simple game) and I want to use Erlang for the server side and Java for the client side. How should I make the connection between client and server? I have never worked with network programming before...
I think that "sockets" is the thing that I should use, am I right? In that case, could I use Java's sockets-class to send/recieve messages on the client and some corresponding sockets-module in Erlang on the server? Or do I have to have some kind of Java receiver on the server and then translate to Erlang? Is sockets some general protocol sent over the network that all languages interprets?
Depends on what you want to learn.
Sockets are low level and you will need design a protocol.
HTTP Rest API is more general, requires web server (yaws for example)
or Jinterface Erlang<->Java bridge
http://www.slideshare.net/dennisbyrne/integrating-java-and-erlang-with-jinterface-presentation
Indeed, Erlang provides a module for Socket programming that you can use. Go with your option number one.
But is such low level programming is a must for you? If not for your game, then consider creating a REST API. It is HTTP after all. Thus you can achieve:
general protocol sent over the network that all languages interprets
Another alternative to sockets and HTTP for creating
some general protocol sent over the network that all languages interprets
is something like Apache Thrift or other interface description languages (IDL). While it doesn't support all languages, it does support both Java and Erlang.
Related
I have a requirement where I need to send message from multiple clients and those clients can be C clients or Java clients to server written in java.
Why I need to send over socket? Because there can be any process in any app on a same system who wants my app to capture there alarms and react accordingly.
Now, I can implement multiple Java clients who can connect to single Java server but how to do the same thing irrespective of it is Java client r C client.
If not socket programming, then what could be the other best way to make this communication happen
All low level network programming is written using sockets. you can have server written in any language communicate with client written in any language. To make this happen we have certain protocol which governs the communication like udp, tcp etc.
high level language provides api which will you to connect any server with single line of code without you needing to create socket. But in C you can create socket and connect it to the server. see this. All you need to know connect server and client is server ip and port...
While your requirements are very broad it looks a lot like a prime candidate for protocol buffers.
https://developers.google.com/protocol-buffers/
Language agnostic.
Platform neutral.
Fast.
Running on ZeroMQ (http://zeromq.org/) where you can push and pretty much run on top of everything.
I'm developing a Client application which talks to a Server using WebSockets. The Client is in C++ and the Server is in Java.
Can anyone suggest me any library which I can use on both Client side and Server side for communication using web sockets.
I never had experience with WebSocket, but try library cURL (libcurl). It was easiest for me to write clients for HTTP and FTP, using it. It have to help (but curl is useful just for clients, not for server).
If you are talking about sockets, normal sockets that connect on a port and wait for a connection on the server side and that connect to a given address on the client side, then I would recommend the boost asio socket on the c++ side and the standard java socket on the java side.
Just remind yourself of making sure that you transmit the datatype you expect.
Another cool implementation for both, java and c++, is ZeroMQ. I would recommend to take a look at it because it is easy to use and has implemented some really cool communication patterns.
I've a doubt in java socket programming. The tcp server is created Java Socket Programming and running in different machine. Now I want to create a client for the server to request some data from server. Am I need to use same Java socket programming or I can use different APIs to communicate with server and get response back?
Thanks,
Pramod
You must also use sockets, but not necesserily in Java. Virtually any programming language can talk to different machines based on TCP/IP or UDP sockets. You can even use tools like nc to test your server.
If the server is using sockets, then yes, the client should also be written using the sockets API. This can be done in any programming language, not necessarily Java.
To give you a broader perspective, there exist other technologies that allow two processes to communicate (RMI, zeromq etc). However, it is almost always the case that both sides of the communication have to use the same technology to be able to talk to each other.
I would like to have the clients query each other through the server without delay ( = no polling interval ).
Example: Server S, clients A and B
Client A wants to request Client B.
Client A will make a request to the server S, no problem there.
Then Server S needs to be able to request Client B but how to do that without polling?
All the node.js/APE (for PHP) technos are designed for the web, however I don't use a web server for that. Does Java has something close to a push technology/framework that is not web?
I would really prefer a solution that doesn't require each client to use their own reserved port (I don't want to end up with 1 WebService per client for example)
Note: all the clients are on the same machine.
A couple of options...
Plain socket communication. java.net.Socket, java.net.ServerSocket. Maximum flexibility but requires knowledge of low level TCP/IP API/concepts.
The good old RMI. Java based RPC layer on top of TCP/IP. Works good when client and server are both in Java and generally in same subnet. May give problems when client and/or server are natted.
Spring Remoting, it's actually pretty decent.
Bi-Directional Web Services. i.e. clients host their own WSes which the Server calls when it needs to do a callback.
JMS as someone already mentioned.
Distributed Data Structures, Check out http://www.hazelcast.com/
Lots of options to chose from, no need for webserver.
If you really don't want to use a web server then I would check out JMS. That being said, all the cool kids are using web servers these days since the protocols are so ubiquitous.
Your use case requires a messaging protocol. We don't really know the scope of your problem but you already said you want a server to exchange requests between clients, so I would go with an existing solution rather than a roll your own approach.
JMS has been mentioned and is certainly a viable Java based solution, another would be XMPP which is a real time communication protocol commonly used for instant messaging.
It is an open standard that has both server and client support in every major language and platform. This would allow you to have standalone apps, web based ones and apps for mobile devices all being able to communicate with each other. The only potential gotcha for your use case is that it is text based. Since you haven't said what requests you want to pass back and forth, I don't know if this will fit your bill or not.
You can use Smack for client side development in Java and any OS server you want.
I have implemented a client server jave program using TCP for an assignment. Now I've to explain why I chose TCP for communication when other alternatives like HTTP are also available..
So I need some reasons why TCP is better than the other one ..
HTTP is not an alternative to TCP. It is a protocol built on top of TCP.
Custom, interactive protocols can be much more efficient when implemented on TCP than on HTTP, because HTTP works on a rather basic request/response base.
On a pure TCP connection, both ends can send messages whenever they want. On HTTP the server can't really proactively send a message to the client. It needs to wait for the client to send a request.
An advantage of HTTP is that it's almost universally understood: there are server- and client-libraries for all languages, there are well-understood caching and proxy-ing mechanisms and there's a wide variety of content negotiation-mechanisms built in.
So it's the traditional trade-off between high-level or lower-level abstraction:
lower-level abstraction (TCP) provides high flexbility and the possibility of implementing almost everything, while it is not as simple to use
higher-level abstraction (HTTP) provides more built-in features and are easier to support, but additional features are harder to add
HTTP is a protocol on top of TCP. It offers specific features and lacks others (most significantly statefulness and the ability for servers to initiate communication). If you need something that HTTP makes hard or impossible, it would be a good idea to use something else.
Or you can kludge those features on top of HTTP, which is what seems to be the most popular option (possibly because of the "only port 80 is open everywhere, so let's use it for everything" issue) but often leads to rather nasty hacks.
TCP can't be told as better. It is a protocol of transport(4th) level of OSI model.
HTTP is an application protocol(7th level).
They are different and HTTP is based on TCP.
HTTP is basically used for web communications - sites, web-services and so on. It can be told that HTTP is a client-oriented: client asks server for some data and receive the response. When it sends another request and so on.
TCP is a base protocol which grants you that all your sent information will be received in the same order and intact.
Read about them on Wiki: HTTP and TCP.