I am trying to get my simple Java TCP/IP server to intercept and respond to my 'GET_NEXT_NUMBER' request command, but the server is not responding to it.
I am doing this by initiating a PuTTy session on 127.0.0.1:8765, where my server instance is running inside my NetBeans IDE.
I have set breakpoints at the following lines:
if (inputLine != null && inputLine.startsWith("GET_NEXT_NUMBER"))
Both of these lines get hit. As soon as I open the connection to the server in PuTTy, handleRequest(clientSocket); gets hit. Then, when I type GET_NEXT_NUMBER into the PuTTy terminal window, the if statement gets hit.
However, things start going wrong from there. I will describe the process flow as I have interpreted it from my IDE:
1) I type in GET_NEXT_NUMBER 2) NetBeans starts flashing its icon in the Windows task bar. The debugging screen gets filled with the correct values 3) The if statement gets hit. I choose 'step over'. Now there is a problem: the if statement's body appears to get completely ignored. I am not sure if this is what is supposed to happen. I don't think this is supposed to happen. It is supposed to go through the lines of the if expression body one by one.
4) The server is supposed to reply by writing something to the System.out, but doesn't. Instead, it immediately moves to closing the socket.
5) Finally, it moves on to accepting new connections.
Now, I don't have this problem at all with the TcpIpClient code. At step 3, it correctly goes through the if statement's body and prints out the "Received request: GET_NEXT_NUMBER" line in System.out like it is supposed to.
Question: when I open a PuTTy session to 127.0.0.1:8765 and I type "GET_NEXT_NUMBER" into the terminal window, am I effectively writing to the HTTP output stream so the server can receive it? It certainly doesn't look like it, because the server is jumping over the if statement for some reason.
If you are using PuTTY then it certainly isn't HTTP, but if your selected a Telnet connection type, then your initial data sent to the server will contain extra information which would normally used to negotiate options for the telnet session. Try selecting a connection type of Raw.
posted 4 years ago
Using the Raw option certainly seems to have fixed it. The code returns the correct reply to the client socket's output stream now.