I have a producer sending data for 15 seconds. I just replicate the same program and run it from different window while the first producer is already running. I get "Port 3333 already in use, java.net.BindException: Address already in use"
How can I make multiple producers (multi-process not threaded) send data at the same socket? However I dont know from where the port 3333 comes into picture.
What might be wrong with my program? I can provide the complete problem statement if desired. However in short I am using custom Kafka Producer to send data and I want two such Kafka Producers to send data.
I guess the program that you are starting is trying to listen for connections on a fixed port 3333, and when you start second instance it gives error of "Already Bound". See if there is a way to change that port using some arguments. But I cannot comment on that as you have not provided any source.
But I am just going to explain how things work in normal scenarios
Suppose consumer is listening on port 3333, then it will become the server and accept the connections on that port. And multiple clients can send data on that port to server
Sample Client Program
BufferedReader inFromUser = new BufferedReader( new InputStreamReader(System.in));
Socket clientSocket = new Socket("localhost", 3333); //3333 is the port on which the server is listening
DataOutputStream outToConsumer = new DataOutputStream(clientSocket.getOutputStream());
BufferedReader inFromConsumer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); //Only if consumer sends something in reply
sentence = inFromUser.readLine();
outToServer.writeBytes(sentence + '\n');
modifiedSentence = inFromConsumer.readLine();
So multiple producers will be clients and send data to consumers who are listening on dedicated ports. Keep in mind multiple consumers will not be able to listen on same socket,
you will have to use different ports for different consumers.
If you have a connection-oriented protocol (e.g. TCP) the server usually only listens for connections on the advertised port. When a client connects, the server's accept call results in a connection on effectively a random other port number, allowing the main server thread/process to continue listening for new connections on the advertised port.
With a datagram-based protocol (e.g UDP) this isn't an issue because no client maintains a persistent connection.
Either solution could work for you--which one to prefer depends on the nature of the traffic.
Related
I'm implementing a FTP program using UDP in Java (TCP is not an option), but I'm having trouble grasping the basics of how it's supposed to work.
As I understand, it's connectionless, so I should just have one server thread running which processes every request by any client.
Where I'm getting confused is during the actual file transfer. If the server is in the middle of a loop sending datagrams containing bits of a requested file to the client, and is waiting for an ACK from the client, but instead of that receives a completely different request from a different client, how am I supposed to handle that?
I know I could jump out of the loop to handle it, but then if the initial expected packet finally arrives, how can I pick up where I left off?
A UDP server works similar to a TCP in many respects. The major difference is that you will not receive a acknowledgement that your packets were received. You still have to know which client you are sending to, so use the DatagramSocket class. This is the Oracle tutorial for UDP: http://docs.oracle.com/javase/tutorial/networking/datagrams/index.html. It has a pretty good example in it. The significant part is getting the address and port of the original client, and returning your packets to that client:
InetAddress address = packet.getAddress();
int port = packet.getPort();
new DatagramPacket(buf, buf.length, address, port);
You could start a new thread on the server side for sending the bits every time a client sends a request. The thread would save the return address and port of the client, and die when the file send was done.
I am implementing the TFTP (trivial FTP) protocol in Java. I have a client and a server, and so far the client can request a file and the server sends him that data.
Here is where I hit my problem - for obvious testing reasons, I run both the client and the server on my machine. However, when sending a file, there have to be two sockets listening on the same port:
the client needs to listen for received data packages
the server needs to listen for the client's acknowledgements
...and also two respective sockets for sending data and acknowledgements, also sharing a port.
This normally does happen on the same port, but on different machines. Is there a way to get around this, and make both client and server work peacefully on the same host, without any ugly hacks? And by ugly hacks I mean something like:
predefined offset for the ACK communication port (such as +15 over the data port; this is what I'm currently using now. It sort of works but it feels wrong and is error-prone)
repeatedly closing and opening sockets (send data, close socket used to send data so that the client can use that port to send his ACK, etc.); this also works at the moment, but also via a hack. Here is, for example, how I "reopen" a socket used for sending things:
public void open() {
try {
socket = new DatagramSocket(localPortCache);
} catch (SocketException e) {
e.printStackTrace();
}
}
This is evil. My sockets, originally, receive dynamically-allocated ephemeral port numbers. I then memorize that value and use it to "restore" my socket to the old port. However, it can't be guaranteed that that port is still available. It usually is, but there's no guarantee. Am I being overly-paranoid in this case?
generating a new ACK-communication port in the handshake and send it to the client via the control port (69) in an additional step
Update:
I have managed to fix my problem. My issue was that I wasn't trying to reuse my sockets. For instance, I sent something from a socket on port X, but then tried to allocate a new socket on that port to listen for the ACK, instead of just reusing the old socket.
The client doesn't need to use a fixed port number. Just bind it to zero. The server should send the response back to the originating client whatever its port number.
I'm writing a piece of UDP networking program (client - server), and I've run into some trouble.
I want to use streams to I/O data, so I googled "udp inputstream" and found UDPInputStream and UDPOutputStream. When I try to use these, however, the program gets stuck when trying to initialize the UDPOutputStream.
This is the line in my code that freezes:
outStream = new UDPOutputStream(InetAddress.getByName("127.0.0.1"), port);
System.out.println("UDP output stream initialized."); // <-- doesn't get called
I checked out the source of the UDPOutputStream, the code gets stuck on this line:
dsock = new DatagramSocket();
Why does the execution hang up on this line? On the server side, I still use my "old", non-stream version of a simple UDP code, and it works. The socket is initialized the same way and it doesn't hang up. I tried to put a port number to the initialization, but it doesn't solve the problem.
Host machines have more than one network interface (for example, 127.0.0.1 for the loopback interface and some other address for the network card; there may be more than one network card).
If you bind to the loopback address 127.0.0.1 then you'll only be able to receive packets sent locally. If want to receive packets sent over the network from a remote machine you must bind to the local IP address (e.g. 192.168.1.100).
Try following:
InetAddress addr = InetAddress.InetAddress.getLocalHost();
outStream = new UDPOutputStream(addr, port);
I want to write a server which listens on the given port for connections and puts sockets into BlockingLinkedQueue from which the consumer thread will read messages. I accept incoming connections in this way:
ServerSocket serverSocket = new ServerSocket(port);
while (true)
{
Socket socket = null;
socket = serverSocket.accept();
queue.put(socket);
}
When I try to connect in parallel from two separate hosts it occurs that responses to the first one are sent to the second one after establishing the second connection. When I change my code to this listed below the second connection is merely refused:
while (true)
{
ServerSocket serverSocket = new ServerSocket(port);
Socket socket = serverSocket.accept();
queue.put(socket);
}
My questions are:
What's the difference between this two situations? Why in the first situation messages are sent to the second host?
How should I refactor my code in order to create separate connections between my server and both hosts and handle them in parallel?
What's the difference between this two situations?
In the first case, you are using the same port for multiple connections. In the second case, you are discarding the server port so any waiting connections for be refused.
Why in the first situation messages are sent to the second host?
Due to a bug in code, not shown here.
How should I refactor my code in order to create separate connections between my server and both hosts and handle them in parallel?
Create a thread for each connection.
I have two wifi modules M1 and M2 that connect to my access point. I have an android phone that connects to the same access point. I have a socket server on my android phone and the two modules join to the server as clients. Now my question is, is it possible to send a string message from my phone to module M1 without having to send anything to M2. I want to choose between clients to send the message to. Is it even possible in Java?
Ok, here goes.
//setting up server
ServerSocket serverSocket = new ServerSocket(8000, 0, IPaddress);
//creating a client socket to accept it
Socket clientSocket = serverSocket.accept();
Now, I accept the client in a seperate thread so that the main thread does not freeze becauz accept() function is blocking.
I don't know how to create a new thread every time a new client connects. Also I dont know how to limit the number of clients that can connect. I need at most 5 clients and no more.
Yes, it is possible. You need to maintain a separate connection to each client. The ServerSocket class has an accept() function which returns a Socket object. That object represents a connection between two points, your server and one client. You can call ServerSocket.accept() multiple times in a loop to accept all incoming connections. Each Socket object returned will be for a different client.
In order to have the server send a message to a specific client, it will need to know which socket belongs to which client, so the clients will have to send some message to the server identifying themselves, and the server will need to read and interpret that message. Then it can respond with the appropriate response for that specific client.
Post your code if you are still having trouble.
UPDATE because you added code to the question: See the Android Documentation about creating threads. That will be a lot of reading beyond this post on stackoverflow.
As to accepting connections and starting threads, just do it in a loop:
for(int i = 0; i<5; i++){
clientSocket = serverSocket.accept();
// start a new thread, passing it the clientSocket as an argument
}
Other possibly useful links:
https://developer.android.com/resources/articles/painless-threading.html
https://developer.android.com/guide/topics/fundamentals/processes-and-threads.html