I am completely new to creating a network connection in java so I apologize if this is a stupid question.
I am trying to create a D&D companion in java that will allow a player to create their character and then send it to the DM so that they can view it and make changes and send it back to the player. I want to be able to make it so that any time a field is changed on one computer it will also be changed on the other computer.
After a bunch of research online I have been able to create a socket connection between the DM(server) and the player(client) and pass a message between the two but I am not sure how a socket connection works after this initial connection is made. My research has not been very clear on this. I have found many resources that have said that java closes the socket after a message has been passed and many that say that the socket stays open.
If java closes the socket then my problem is easy enough to solve because then I will just have to open a new socket every time I need to pass data making sure that I pass the IP address of the client to the server the first time I make a connection.
My real questions come in when a socket stays open.
If the socket stays open and multiple clients connect to the server, will the server just shout over the network whenever it transmits a message so that all clients receive the message? (If this is the case then I know I can just attach a username to the front of the message so that the client can determine if the server is talking to it.)
If the server does not shout then how do I specify which client I want the server to talk to?
Will I have to add a loop to my receive methods so that the client/server is constantly listening for a transmission from the server/client or will java automatically do so after I run the method the first time?
I have found many resources that have said that java closes the socket after a message has been passed
You found them where?
and many that say that the socket stays open.
All those are correct. Java never closes connections. The application closes connections.
If java closes the socket then my problem is easy enough to solve because then I will just have to open a new socket every time I need to pass data making sure that I pass the IP address of the client to the server the first time I make a connection.
It doesn't.
My real questions come in when a socket stays open.
If the socket stays open and multiple clients connect to the server, will the server just shout over the network whenever it transmits a message so that all clients receive the message?
No. It will respond via the socket that is connected to the corresponding client.
(If this is the case then I know I can just attach a username to the front of the message so that the client can determine if the server is talking to it.)
Unnecessary.
If the server does not shout then how do I specify which client I want the server to talk to?
The server responds via the same socket it read the request from.
Will I have to add a loop to my receive methods so that the client/server is constantly listening for a transmission from the server/client
No, you will have to add a thread per accepted socket, that loops reading requests until end of stream.
or will java automatically do so after I run the method the first time?
No.
You seem to have been reading some truly appalling drivel. Take a look at the Custom Networking section of the Java Tutorial.
Adding to EJP's wise answer, it might be worth clarifying:
Sounds like you (wisely) use TCP, so your Socket represents a connection between 1 server and 1 client. No "shouting". In examples such as this , when connection is established (namely, client obtains a Socket by calling "new Socket" and server obtains a Socket by calling "accept"), those Sockets are dedicated to those 2 specific endpoints. So if 10 clients connect to 1 server, the server will keep 10 Sockets and won't mix them up. A bit like a poor secretary that has 10 phones on his desk and answers them all - despite the mess, each earpiece is clearly connected to 1 customer.
The connection can hold for a while & serve several messages. It will terminate when either one of the sides calls 'socket.close', or it can be terminated by underlying 3rd parties (operating system, proxies, firewalls).
For your first version, or for simple business requirements, it's probably enough to converse over this 1 simple connection. However, for commercial critical data that requires 'assurance of delivery', you might need to invest some careful thought & possibly tools such as RabbitMQ.
Good luck:)
Related
I have to write a program in which clients send the server some number and wait to its response, other random number. It works Infinitely-send number and wait for response and so on...
I would like to write a server which gets a lot of connections ( and creates sockets) how can I do that in effeicient way (without creating thread to every socket created)?
Is it better to open and close sockets for every request and response?
Is there a way to send answer over a socket when I don't know which one is the right socket, but I know that all the sockets starts from the same client computer and I know the port source of the client
(I thought about making sockets array)
how can I do that in effeicient way (without creating thread to every socket created)?
You are assuming without proof that a new thread per socket is inefficient. It isn't.
Is it better to open and close sockets for every request and response?
No. Take a look at the history of HTTP. The major change between 1.0 and 1.1 was the introduction of persistent connections, which was done regardless of server-side architectures.
Is there a way to send answer over a socket when I don't know which one is the right socket
I don't understand how that situation could possibly arise. The answer only makes sense in the context of a specific session, which is associated with a specific socket. If you aren't retaining that information you should be. It's just a data structure problem.
but I know that all the sockets starts from the same client computer and I know the port source of the client (I thought about making sockets array)
If you can remember the source port you can remember the socket itself. Again, this is just a data structure problem. And there is no need for the assumption/constraint that all connections are from the same client. And unless that client is multi-threaded there is no need for multiple connections from it at all.
I have an application where the user (client #1) enters a local ip and a port and the application sends a picture to client #2 (who is also using the same application). However for the final application, I do not want the user to enter the local ip because they will not know this information, and I want my program to automatically figure this out.
My first idea:
Originally, I thought that I could scan all the local ip's for an open port, but this would take way too long.
My second idea:
My next idea was to have the clients send their local hostnames to a remote server which then swaps them and sends them back to the clients.
However, I do not want to run a dedicated server for my second idea.
Because this is more of a design question, I am not including any code but I will do so if necessary.
Do you guys have any ideas on how I should design my application to automatically figure out the local ips?
I did try to google this but couldn't figure out a solution, and so I gave up after an hour and just put my question here.
you can use something like jgroups (allowing discovery based on multicast [lan] etc) or some peer-to-peer implementatons for that, although the latter require at least some servers for initial discovery.
in principle that works the way, that the clients send a message out to "the world" using some well known address and wait for someone to answer. each client itself waits meanwhile for such a message and replies it with information how to "connect" to the current client. This can be done via a so called blackboard, where this bb is either a special tcp-address for multicast-messages (the os/tcp sends the message to all clients listening concurrently) or one or more servers (seeds) that take and coordinate the request and the "membership" lists. anyway, there are some tools ;)
I'm making a java program & I want this to be both as server and a client (using sockets). How is this best achieved?
If you mean that you want to both send and receive data, a single regular socket (on each computer) will do just fine. See Socket.getInputStream and Socket.getOutputStream.
The usual "server" / "client" distinction just boils down which host is listening for incoming connections, and which hosts connect to those hosts. Once the connection is setup, you can both send and receive from both ends.
If you want both hosts to listen for incoming connections, then just set up a ServerSocket and call accept on both hosts.
Related links:
Official trail: The Java™ Tutorials, Lesson: All About Sockets
If you want each station to function as a server and a client, like a p2p chat,
you should implement a thread with a ServerSocket, listening for incoming connections, and once it got a connection, open a new thread to handle it so the current one will keep on listening for new connections.
For it to be able to connect to others, simple use SocketAddress and Socket, in a different thread to try to connect to a specified server address (e.g. by a list of the user's friends)
you can find plenty of chat examples by googling.
cheers.
If you want the program to perform the same operations regardless of whether it is a server or a client for a certain connection, I could imagine handing off both the client Socket and the ServerSocket.accept()-produced socket to the same method for processing.
Have a look at jgroups it's a library that allows the creation of groups of processes whose members can send messages to each other. Another option would be to use hazelcast...
You may also look at this question.
The best way to do this is to run the server on a thread:
You run server.accept() therefore while your program is listening for a connection on that thread you can do whatever you want on the main thread, even connect to another server therefore making the program both a server & a client.
Ok so I've found out Sockets are not serializable... so I cant pass them over TCP...
My problem is I have a homework assignment where I have 10 servers that must listen on one socket(lets call it request). For input from any of x number of clients that write to that socket. Then after one of the server processes reads a message from request it must communicate with that client over its own socket...
I tried making each server socket and the request socket on the server side, then passing those to the clients when they connected to the server... but this doesn't work...
Any tips on how I might do this? Having TCP not be 1-1 is really toying with me here.
Passing a socket over a TCP connection is like trying to pass a telephone over a telephone call, or trying to fax your fax machine. What you need to do is organize another connection between the parties concerned.
EDIT: In fact your assignment as stated doesn't even make sense:
I have 10 servers that must listen on one socket(lets call it
request).
That's not even correct terminology. Servers listen at ports, not sockets, and 10 servers listening at one port is impossible. They must each have their own port.
For input from any of x number of clients that write to that socket.
See above. Clients don't write to 'that socket'. They create their own socket that is connected to the server port, and they write to that.
Then after one of the server processes reads a message from request it
must communicate with that client over its own socket
If the server has received a connection from a client it already has a socket representing its endpoint to that connection. So all the server has to do is write the response back to the same socket it read the request from.
In short you have a major terminology problem, but you don't have a software problem at all.
Passing sockets seems crazy to me. If you're trying to write a better server, you'll have a hard time beating Netty. I'd recommend giving it a look.
I just programmed a Java Server-Client Chat (with multiple clients) where they log in, chat and log out. The socket is always started and I listen in a loop.
Now I have to program this kind of chat where the connection isn't always open, so the the connection just stars "on request" (when someone sends a message).
How do I do this? Could you give me some keywords which I should google?
If you want to create a Server and Client that does not have a Open Connection (Correct me If I am wrong) you will have to Open and close the connection manually. As these "connections" represent Streams across the network.
Another Option you can consider is maybe using UDP, but this does not close and open a connection on request it only removes the overhead of TCP and it's reliability features.
From the Datagram Lesson on Oracle.com:
Some applications that you write to
communicate over the network will not
require the reliable, point-to-point
channel provided by TCP. Rather, your
applications might benefit from a mode
of communication that delivers
independent packages of information
whose arrival and order of arrival are
not guaranteed.