Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I was planning to create a chat messaging application wherein two or more clients can communicate but I am a little confused.
Does java can have a client to client communication using sockets?
Does the socket communication always needs a server?
Is it possible that one client will stand a server of the communication?
Do you have any tutorials for a client to client communication?
If the communication needs a server, how a can a client A see Client B's messages?
Client to client communication does not makes any sense because once a system start receiving message it is termed as server, so in communication there should be a server and client to communicate else the situation will be like two people talking and none of them listening.
Client A can act as a server and client both and so the client B,
in doing so both can communicate in two way ie send and receive information.
Yes, java can work with sockets.
For example, an "official" tutorial from Oracle: http://docs.oracle.com/javase/tutorial/networking/sockets/
But working with sockets directly requires a lot of code for encoding/decoding message from/to a binary form, separating data stream to logical "packets", handling threads and message queues, etc. Fortunately, there are network libraries which make this process much more easier. I would recommend Netty: http://netty.io/
About client/server relationships. If we are talking about TCP/IP, then yes. One side (server) always listens for connection, and the other side (client) opens a connection to the server.
If you are using UDP, however, from network point of view, all participants are equal. They just send and receive UDP packets.
Back to your chat application: the most simple solution - all clients connect to the dedicated server. Every chat message contains client id. When the server receives the message, it sends it to the client with the specified id. Thus, every client can transfer message to every other client. The server works as a "dispatcher".
If you need simple approach you can try https://httprelay.io service. What you need is just http client and no external libraries.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
So I previously asked a question if you can send a client that's on a ServerSocket to a different Server. But now, I'm asking how are the players for minecraft sent from server to server using Bungeecord and/or Lilypad. I know that LilyPad uses proxies and that stuff, but how are the players, when connected to the Bungeecord/Lilypad server, sent to a hub/spawn and/or to other servers, for example a survival server and a creative server. You can find servers like this on servers that have networks. I know that Treasure wars uses lilypad, if that helps.
You answered your own question. Both Bungeecord and LilyPad are proxy server networks.
Though a server cannot redirect the client to another server without permission, the server can connect to another server (meaning the first server is a proxy) and send back that server's messages to the client. As the first server is, in essence, also a client to the second server, the first server can switch connections at any desired point.
In other words, the Minecraft client does not switch connections at any point. The IP of the server to which the Minecraft client is connected never changes, and it is that of the proxy. However, what does change is the server to which the proxy is connected. If the client sends some message to the proxy stating that it wishes to go to the hub, the proxy then disconnects from whatever server it is currently connected to, connects to the hub, and sends back to the Minecraft client whatever messages the hub responds with.
This is my understanding based on a quick search.
However, if the Minecraft client was modded as well, it would be possible to have a similar network without the need for a proxy like so:
Client interacts with the server in such a way (maybe the player walks into a portal) as to trigger some server-switching action.
The server recognizes this interaction and, as both it and the client are modded, knows how to respond. The response is simply the sending of a message to the client, saying, "Switch to a different server. Here is the IP: (Insert IP here)"
The client receives the message from the server and, by its own will, disconnects from the current server and reconnects to the new one.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I wanna program my own renderfarming tool in Java for the Blender render engine..
But know i wanna know what is better for doing that: TCP-IP or UDP?
Thanks
I assume you want to have the reliability for your renderfarm, so data that is sent to the user contains the exact quality he or she expects, without anything weird that occurs because a packet is missing. You definitely don't want frames being skipped or sloppy. So I would suppose TCP-IP is the better choice here.
Also see:
When is it appropriate to use UDP instead of TCP?
http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/
TCP/IP is a reference model whereas UDP is a protocol in this reference model. So, basically you can't compare these two. As, IP is another protocol in this model, at network layer, i think you mean to compare TCP and UDP, as they both belong to same layer, transport layer.
Which protocol is better, depends on what you want to do. For some requirements, TCP is better, for some, UDP.
TCP is a slow but reliable (ensuring that data is delivered) and connection-oriented protocol whereas UDP is fast but un-reliable and connection-less protocol.
TCP should be used when you need the data to be delivered surely (like downloading an application). UDP should be used if you need to deliver data most of the times(like sound or video chatting). By most of the times, we mean that while sending thousands of small data units, we can manage if we miss a few of them.
I hope, now you can decide which protocol to choose for you job.
It depends on the type of application that you are going to use. Make a note that TCP and UDP are transport layer protocols and do not mix it up with network layer protocol (IP).
TCP protocol :
It is a connection-oriented streaming procotol . It is Heavy weight as it does 3 way handshake for connection establishment, flow control for network congestion , re-transmission for error correction and also ensures ordered packet delivery.
You can select TCP for following applications :
Applications that can accept delay but cannot compromise on packet loss or ordering of packets. (i.e, it is suitable for delay insensitive applications and for reliable packet transfer applications.)
Example for applications using TCP :
FTP
HTTP
UDP protocol :
It is a message based connection-less protocol. It is Light weight as it does not have handshake mechanism for connection establishment or flow control for congestion or re-transmission mechanism. Also, it need to worry about the order of the messages.
You can select UDP for following applications :
Application that can tolerate packet loss or un-ordered packet delivery but cannot compromise on delay or jiter. (i.e, it is suitable for real-time applications and for applications that do not worry about packet loss)
Application that do multicast
Application that do small transactions (Example - DNS lookup, Heartbeat/Path monitoring communication messages, Logging)
Example for applications using UDP :
VoIP
DHCP
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have a server written in Java which basically awaits requests from different clients and serves their requests. I am running this server from Eclipse. This server is accessible on the local network but I want to be able to access this service from outside the local network. Is there any way to do this please?
P.S. I am a real beginner in these things
you can open a port in the router that leads to the one that the server is listening on. You then connect to your public IP. This ip can be found on
As #Java Player said, the problem is that your router(Nat) denied any incoming packet to your local network...briefly, there is many solutions for this:
Third party server: you must have a dedicated server that plays the role of intermediary, between your client/server programs.
Pros:
Solve completely the problem related to the Nat.
Cons:
In addition of your client, you must code another third party that forward packet to the desired destination.
BTW it gets a little heavy(waste of bandwidth).
Reversed connexion: the server and the client program are reversed, that's mean the client become a server and the server become a client, 'used by most of trojan...
Pros:
Very easy to implement this approach.
cons:
You must at least has an opened port.
Udp hole punching: this approach is used by perhaps all peer2peer solutions(eg: skype, utorrent...).
Pros:
You don't need to any router configuration.
Direct connection between peers.
Cons:
You need also a third party server called STUN server to get informations about your router.
Not all router that works with udp hole punching, you must consider also the first solution.
Writing a hole punching solution is not easy task.
You could also download something like Hamachi and then download Hamachi and sign into your network on the other PCs and Macs (and Linux...which is currently in beta). Then you'll want to be able to access your server on.
Main Hamachi product page
Linux Beta
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I have two clients (A and B) and Servlet. I want, when A client send a request to the SERVLET, SERVLET redirected the request to the client B and client B send response back to the client A. CLIENT ARE NOT SERVLETS!!! They are ordinary socket clients, consequently IS NOT possible classic servlet redirect!!
Do you have any suggestions for troubleshooting???
Thanks a lot!!!!
Firstly, you can't serialize a HttpServletRequest or HttpServletResponse using Java serialization. Objects that conform to these APIs typically include references to "stuff" in the servlet implementation stack that is inherently non-serializable.
Second, you can't "redirect" a request to another client. It doesn't make sense from the perspective of the HTTP protocol.
A redirect happens when a client sends a request to a server and the server response has a 3xx status code that says "try that request somewhere else". It is a redirection to a different server, not a different client.
Even ignoring the details of what redirection means. You can't send an HTTP request to something that is in the HTTP client role. It won't be expecting it (listening for it), and wouldn't know what to do with it. (And indeed it would be a violation of the HTTP protocol.)
Thirdly, an "ordinary socket client" can't talk to an HTTP service (implemented using Servlets, or anything else). The client has to implement at least a subset of HTTP protocol in order to make itself understood by the HTTP service. It is possible to implement that "by hand", but IMO that's a bad idea ... when there are high quality implementations you can use for free.
In short, what you seem to be trying to do is impossible / nonsensical. (If I understand your Question correctly ... which is debatable.)
If you explained what you were actually trying to do here, we might be able to suggest sensible alternative approaches.
I'm trying to connect two java client applications across server. The client will be able to communicate directly with other client.
Literally you can't do that using HTTP. But you could build an HTTP server/servlet that transfers messages from one client to another; e.g.
Client A sends a PUT request containing a message for A to server.
Server stores message and replies to client A.
Client B sends a GET request asking "any messages?" to server.
Server looks up messages and responds with the message from A.
But note that you can't do that with plain socket clients. The clients have to be HTTP clients.
If you were prepared to ditch the requirement that the server was an HTTP server / servlet, you could have "simple socket" clients open duplex connections to the server, and have the server pass "messages" between the clients. This entails implementing a custom "protocol" for messaging.
A third alternative is to use an existing RPC or object broker technology; e.g. RMI, CORBA, ICE, etcetera
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am trying to set up a P2P instant messaging system, and while I haven't hit the issue yet, I expect I will have some issues if the client is behind NAT on a local LAN (read: Everyone.)
Let me explain the algorithm and you'll see what I mean. There are three components: A server and two clients - Client Alice wants to initiate a chat with Client Bob. The server only keeps track of who is online, but the actual conversation doesn't go through the server (for privacy for the clients)
So, Alice and Bob both sign in to the server - Connecting to the server's static listening port from an ephemeral port. They tell the server what static port they are listening on for incoming chat requests. Alice asks the server how she can contact Bob. The server responds with the ipaddress and listening port, among other things. Alice sends the request to Bob on that IP address and port to establish the connection. Hope that makes sense.
If Bob is behind NAT, then sure he can talk to the server because he's the one who starts the communication. But Alice's request won't get to him because the NAT relationship hasn't been set up yet for the port he's listening on for chat requests, from Alice's IPaddress.
Is there some kind of black magic that someone knows to make this work? Will it be a non issue? Development isn't that far along, I haven't actually hit this problem yet.
To state the obvious, I don't want to have to make end users configure port forwarding for their listening ports.
For the aforementioned black magic, client and server are both in java, but I'm just generally after the algorithm (and if it's even possible)
Check ICE.
Most P2P frameworks, like JXTA in Java, use the principle of relay servers.
Say A wants to connect to B and B is behind a firewall.
- both A and B establish ** outbound ** synchronous (or full duplex/websockets) connections to Relay Server R
- A signals to R that it wants to transmit data to B
- R 'binds' the inbound connection from A to the outbound connection to B (the synchronous HTTP response to B for instance)
- A sends data to R which is relayed to B
The key thing here is that all connections are established outbound (an usually using a friendly firewall protocol like HTTP on well known ports)
Things get obviously a bit more involved when you have distributed relays; you then need 'routers' that maintain routes to various peers via the relays which rely on Distributed Hashmaps (DHTs) to maintain the information.
There is no black magic. If both clients are behind NAT the message has to go through a third party (the server).
And I would consider using such architecture for all communication if it's only about text messages (you can think of some kind of encryption if privacy is an issue). The server (or servers) will be more loaded but you get simpler (and in some cases more reliable) architecture. For instance, if Alice sends message to Bob, and Bob has some network issues, the server can queue and keep the message for some time and deliver it later (even if Alice goes offline). Another thing is conference (group) chat. Handling it with P2P only is much more challenging (but can be very interesting). But if all clients are behind NAT you get the same problem.
I would also strongly suggest implementing an application-level acknowledgment mechanism for all transmitted and received messages (both from client and server). Protocols such as TCP/IP are not reliable enough.