I am playing around with an object server , and have run onto an issue with the port

My client sends information on port 9999.

My server listens to port 9999.

However, whenever I receive an incoming connection,

System.out.println("" + socket.getRemoteSocketAddress() );

gives me an incrementing port number !

/127.0.0.1:56304
You said: Moo
/127.0.0.1:56305
You said: Baa
/127.0.0.1:56306
You said: Quack

Do you know what is causing this, and how to fix it ?

***

Client

***

public class Client {
	
	int port;
	String url;
	Socket socket;
	ObjectInputStream input;
	ObjectOutputStream output;
	
	public Client(String address,int po){url = address; port = po;}
	

	public void out(Object obj){
		try{
			socket = new Socket (url,port);
			output = new ObjectOutputStream (socket.getOutputStream());
			output.writeObject(obj);
			socket.close();
		}
		catch(Exception e){
			System.out.println("Client Crash\n" + e);
		}
	}
}

***

Server

***

public class Server implements Runnable {
	int port;
	ServerSocket ssocket;
	Socket socket ;
	ObjectInputStream input;
	Object dump;
	TestObj to;
	
	public Server(int por){port = por;}
	
	@Override
	public void run() {
		try{
			ssocket = new ServerSocket(port);
			
			while (true){
			socket = ssocket.accept();
			System.out.println("" + socket.getRemoteSocketAddress() );
			input = new ObjectInputStream(socket.getInputStream());
			dump = input.readObject() ;
			socket.close();
			to = (TestObj) dump;
			to.say();
				}

			 } 
		catch (Exception e){
			System.out.println("Server Crash\n" + e);
		}
		
	}
}

So, first things first...

Creating and destroying a socket every time you want to send a message is a horrible idea. It's slow, and messy.

Secondly, there's no "port mismatch" here, the server is listening for connections on port 9999. In TCP the listening port does not accept messages. Instead it negotiates a connection which is given another port number to not get mixed up with the listening port.1

1 This is not perfectly accurate but serves reasonably well as a basic explanation of what is going on. For more information I highly suggest you buy a decent book on TCP/IP and networking in general.

I think Washu's explanation is a little to over-simplified. It is actually the case that, if a server is listening on port 1234, and accepts a connection, packets through that connection do arrive on port 1234 (although at the API level, they will be routed to a socket other than the listening socket.)

In TCP, a connection is identified by a four-tuple: Destination IP, Destination Port, Source IP, Source Port.

When a client connects to a destination IP and port (like www.google.com:80,) the source IP is determined by the network address of the client, but the source port is generally randomly chosen by the kernel/network implementation on the client.

When one host extracts the "remote address" for a connection, it gets the IP/port of the other box. Thus, if "Destination" == "server," then the server will see Source IP, Source Port, and that port will be randomly allocated by the source. UNLESS the source binds the socket to a port before attempting to connect -- this is POSSIBLE, but it is pretty much always a bad idea. (For example, there's no guarantee that that port will be available on the host.)

There is another gnarl in the story: If the client (initiator of the ocnnection) is behind a NAT router, such as a typical cable modem or WiFi router, then the Source IP, Source Port that the client provides will be substituted by the router to some other Source IP, Source Port. However, the substitution will be made "back again" for returning traffic, so the client/server communication will still work.

So, first things first...

Creating and destroying a socket every time you want to send a message is a horrible idea. It's slow, and messy.

I have fought with this, however if I do not set the code up the way I have it, I get null pointer errors ...

This version gives null pointers

public class Client {
	
	int port;
	String url;
	Socket socket;
	ObjectInputStream input;
	ObjectOutputStream output;
	
	public Client(String address,int po){
		url = address; 
		port = po;
		try {
			socket = new Socket (url,port);
		} 
		catch (Exception e) {
			System.out.println("Client Ini Crash\n" + e);
		}
	
	}
	public void out(Object obj){
		try{
			//socket = new Socket (url,port);
			output = new ObjectOutputStream (socket.getOutputStream());
			output.writeObject(obj);
			//socket.close();
		}
		catch(Exception e){
			System.out.println("Client Crash\n" + e);
		}
	}
}

You don't need to recreate your ObjectOutputStream each time either. Just create it once, when you're connected.

null pointer ...

null pointer ...

Then you're doing something wrong.

You should only need to create the socket once, and you should only need to create one output and one input stream.
Also, if you use TCP, the socket needs to be either connected, or accepted, before you can communicate on it.

in the win32 c api you must initialize the WSAStartup before using socket connections, could it be a similar problem with Java?

Investigating and fixing something like a NullPointerException is Java 101 stuff. If you cannot do that, then I don't think it is time to be venturing into network programming. You need to focus instead on bringing your debugging skills up to speed first.

First hint: exceptions have stack traces.

Second hint: by default, the Java runtime will catch unchecked exceptions and log them *with* the stack trace

Third hint: do not catch exceptions unless you have some interesting error handling behaviour

Fourth hint: if the Java compiler is forcing you to handle an exception, but you don't want to handle it locally, either add it to the method signature or wrap it in a sub-class of RuntimeException.

It is definitely possible to write this code without getting these exceptions. This is simply a bug in your code.