I've a target machine(*nix based) which is connected to my machine(local to my pc). I want to execute some commands on this target.
So, I'm using Java socket to achieve the same.
socket = new Socket("100.200.400.300", 23, null, 0 );
remote local
Here, after the above line -
socket.isConnected() returns true.
Now, I've I/O streams of this Socket object and I'm doing -
while((string = bufferedReader.readLine()) != null) {
outputStream.write(string .getBytes());
outputStream.flush(); }
Buffered reader to read commands from a local file and write to the socket object for execution on the target machine. Below code to read from Socket -
while((myIntVar = is.read()) != -1) {
//Below line prints some junk data ... hash, updaward arrow and spaces and then
// loop hangs to raise a Socket I/O exception.
System.out.println((char) i);
stringBuffer.append((char) i);}
Here, my understanding is that, as I already have the socket connection established, I can just pass my commands and those commands should get executed on the other side(correct me if am wrong).
But this is not working. I'm getting junk characters as I've mentioned above and there is one more thing - I'm not passing username and password for establishing the socket connection - do I've to pass it as we do for telnet(how...? am lost here).
And, just for info - the above code is all that I've(no server or client code as mentioned in various other threads) .
Telnet does not quite use raw sockets as you have. Telnet has special ways of end lines and ending messages. You will need to work out the correct protocol to use, there are actually several varying implementations of telnet. It may be easier to use a library.
An easy work around would be to filter any character that does not fall in the correct ascii range we want.
private static String cleanMessage(String in) {
StringBuilder sb = new StringBuilder();
for (Character i : in.toCharArray()) {
int charInt = i.hashCode();
if (charInt >= 32 && charInt <= 126) {
sb.append(i);
}
}
return sb.toString();
}
The Apache Commons library has an implement of Telnet handling, with an example here
Related
I am trying to write a simple echo server using SSL. The first line that goes to the server is echoed exactly. When I send a second line, only the first character is echoed. The client works off of a buffered reader's read line from stdin. If I hit CR again the rest of the message comes through. The server seems to be sending all of the data. Here are output from client and server:
CLIENT:
Sending to server at 192.168.0.161
on port 9999
4 seasoNS
echo:4 seasoNS
are really good
echo:a
echo:re really good
SERVER:
server listening on 9999
has cr/lf
4 seasoNS
size to send: 10
has cr/lf
are really good
size to send: 16
exiting...
Here is the client loop:
try {
BufferedReader consoleBufferedReader = getConsoleReader();
sslsocket = getSecSocket(strAddress, port);
BufferedWriter sslBufferedWriter = getSslBufferedWriter(sslsocket);
InputStream srvrStream = sslsocket.getInputStream();
String outMsg;
while ((outMsg = consoleBufferedReader.readLine()) != null) {
byte[] srvrData = new byte[1024];
sslBufferedWriter.write(outMsg);
sslBufferedWriter.newLine();
sslBufferedWriter.flush();
int sz = srvrStream.read(srvrData);
String echoStr = new String(srvrData, 0, sz);
System.out.println("echo:" + echoStr);
}
} catch (Exception exception) {
exception.printStackTrace();
}
This problem seemed so odd that I was hoping there was something obvious that I was missing.
What you're seeing is perfectly normal.
The assumption you're making that you're going to read the whole buffer in one go is wrong:
int sz = srvrStream.read(srvrData);
Instead, you need to keep looping until you get the delimiter of your choice (possibly a new line in your case).
This applies to plain TCP connections as well as SSL/TLS connections in general. This is why application protocols must have delimiters or content length (for example, HTTP has a double new line to end its headers and uses Content-Length or chunked transfer encoding to tell the other party when the entity ends).
In practice, you might not see when your assumption doesn't work for such a small example.
However, the JSSE splits the records it sends into 1/n-1 on purpose to mitigate the BEAST attack. (OpenSSL would send 0/n.)
Hence, the problem is more immediately noticeable in this case.
Again, this is not an SSL/TLS or Java problem, the way to fix this is to treat the input you read as a stream and not to assume the size of buffers you read on one end will match the size of the buffers used to send that data from the other end.
I am making a client socket connection with a hardware device. I am sending a command to this connection to be process by hardware. Now as a acknowledgment or as a reply, the hardware sends a response.
The application sends a command to the connection periodically say in 10 seconds.
Now there exists a problem randomly that the response won't gets synchronized with the sent command from the application. I was thinking of this as hardware specific but to my surprise, when I see the response by connecting putty to the same hardware at same port, I can see that response always gets synchronized. This looks like putty under the hood using some criteria to map the request to response.
Below is the programming steps that I am using to send a command to hardware device:-
Socket clientSocket = new Socket(<IPADDRESS>, 4001);
DataOutputStream outToServer = new DataOutputStream(
clientSocket.getOutputStream());
BufferedReader inFromServer = new BufferedReader(new InputStreamReader(
clientSocket.getInputStream()));
while (true) {
try {
//Get command randomly from array enums for test
Random r = new Random();
Commands[] array = Commands.values();
String command = (String) array[r
.nextInt(Commands.values().length)].getCommand();
outToServer.writeBytes(command);
Thread.sleep(500);
while (!inFromServer.ready()) {
}
System.out.println("COMMAND "+command+", SERVER RESPONSE: "
+ inFromServer.readLine());
Thread.sleep(1500);
} catch (SocketTimeoutException se) {
//Handle Exception
} catch (SocketException se) {
//Handle Exception
}
Can anybody gives a advice how the synchronization of response with request can be achieved as mechanism like putty?
Putty doesn't know any more about your device than you do. The problem is in your code. Get rid of the ready() test and the sleep(). Just call readLine(), if you can be sure that the device sends lines, otherwise just call InputStream.read().
Remove the thread sleep, and rewrite read like this:
String line;
while ((line = inFromServer.readLine()) != null) {
System.out.println("COMMAND "+command+", SERVER RESPONSE: "
+ line);
}
This code can still hang, if the device sends the last message without the newline character \n. Your original code skipped the input.
The main problem is with this line:
while (!inFromServer.ready()) {
InputStreamReader#ready is OK to use only when you have other means to know that all the data has been sent:
Tells whether this stream is ready to be read. An InputStreamReader is ready if its input buffer is not empty, or if bytes are available to be read from the underlying byte stream.
The first message will get read, but that empties the buffer, and when the second message arrives your code isn't reading anymore. You would have to have as many loops as there are messages from device, and that's not practical, at least. And in that case also, it would probably not work all the time.
On the other hand the BufferedReader#readLine:
Returns:
A String containing the contents of the line, not including any line-termination characters, or null if the end of the stream has been reached
will read until all the data that was sent has been read. But if your device send no new line character, then this method will never read the line - the code will hang with all the data in the buffer. In that case you should use InputStreamReader#read as EJP suggested:
Returns:
The character read, or -1 if the end of the stream has been reached
I strongly suggest that you read the IO Streams official tutorial.
Generally speaking, waiting is not done by Thread.sleep and busy waiting (executing empty statements), e.g.:
while (true) {} /*or*/ while(true);
The CPU is executing the empty statement, and it could be doing some other work while waiting on this one to complete. It is a bad practice.
If you want to know more on how to implement waiting I recommend reading the official concurrency tutorial or this one for a broader approach on the matter.
I want to recognize end of data stream in Java Sockets. When I run the code below, it just stuck and keeps running (it stucks at value 10).
I also want the program to download binary files, but the last byte is always distinct, so I don't know how to stop the while (pragmatically).
String host = "example.com";
String path = "/";
Socket connection = new Socket(host, 80);
PrintWriter out = new PrintWriter(connection.getOutputStream());
out.write("GET "+ path +" HTTP/1.1\r\nHost: "+ host +"\r\n\r\n");
out.flush();
int dataBuffer;
while ((dataBuffer = connection.getInputStream().read()) != -1)
System.out.println(dataBuffer);
out.close();
Thanks for any hints.
Actually your code is not correct.
In HTTP 1.0 each connection is closed and as a result the client could detect when an input has ended.
In HTTP 1.1 with persistent connections, the underlying TCP connection remains open, so a client can detect when an input ends with 1 of the following 2 ways:
1) The HTTP Server puts a Content-Length header indicating the size of the response. This can be used by the client to understand when the reponse has been fully read.
2)The response is send in Chunked-Encoding meaning that it comes in chunks prefixed with the size of each chunk. The client using this information can construct the response from the chunks received by the server.
You should be using an HTTP Client library since implementing a generic HTTP client is not trivial (at all I may say).
To be specific in your code posted you should have followed one of the above approaches.
Additionally you should read in lines, since HTTP is a line terminated protocol.
I.e. something like:
BufferedReader in =new BufferedReader(new InputStreamReader( Connection.getInputStream() ) );
String s=null;
while ( (s=in.readLine()) != null) {
//Read HTTP header
if (s.isEmpty()) break;//No more headers
}
}
By sending a Connection: close as suggested by khachik, gets the job done (since the closing of the connection helps detect the end of input) but the performance gets worse because for each request you start a new connection.
It depends of course on what you are trying to do (if you care or not)
You should use existing libraries for HTTP. See here.
Your code works as expected. The server doesn't close the connection, and dataBuffer never becomes -1. This happens because connections are kept alive in HTTP 1.1 by default. Use HTTP 1.0, or put Connection: close header in your request.
For example:
out.write("GET "+ path +" HTTP/1.1\r\nHost: "+ host +"\r\nConnection: close\r\n\r\n");
out.flush();
int dataBuffer;
while ((dataBuffer = connection.getInputStream().read()) != -1)
System.out.print((char)dataBuffer);
out.close();
I am working in the communication between two programs, one in C++ and the other in Java, connected using standard sockets. Both programs run under UNIX (Ubuntu) within the same machine and share information for a period of time in regular basis. At some point of the execution and always at the same point it gets stuck since the program in C++ sends the information and the one in Java does not get all the info so they block since the first expect to receive that and the second is not sending anything because did not receive the information in the firs place.
The odd thing is one you execute the program in Java under Windows. Then it works fine, the program ends correctly without any blocing.
I think is an issue with the Java application but why the difference between running the under Ubuntu or Windows? Do the socket behave differently? Is some parameter different from the JVM in Ubuntu and Windows?
Thank you very much in advance!
Julen.
EDIT:
This the code in the Java side that reads the buffer:
if (task.equals("receiving")){
try {
BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
out = socket.getOutputStream();
// receive messages
char[] length = new char[5];
while (!socket.isClosed()&&(!socket.isInputShutdown())){
in.read(length,0,5);
// this way of reading the length implies that only one command
// at a time can be received and interpreted, so far the iCS does not
// concatenate more commands in one transmission
int commandLength = length[4];
System.err.println("Speed Advice --> command received with length "+ commandLength);
char[] command = new char[commandLength - 1];
in.read(command,0,commandLength - 1);
/*if (cow){
System.err.println("Speed Advice --> Last byte received for X-pos is "+(int)command[commandLength-1]);
}*/
readCommand(command);
}
System.err.println("Speed Advice --> Socket was externally closed.");
in.close();
closeConnection();
}catch (Exception e) {
e.printStackTrace();
}
}
And this C++ sending information:
void
Socket::
send( std::vector<unsigned char> b)
throw( SocketException )
{
if( socket_ < 0 ) return;
size_t numbytes = b.size();
unsigned char *const buf = new unsigned char[numbytes];
for(size_t i = 0; i < numbytes; ++i)
{
buf[i] = b[i];
}
if (verbose_)
{
cerr << "Send " << numbytes << " bytes via tcpip::Socket: [";
for(size_t i = 0; i < numbytes; ++i)
{
buf[i] = b[i];
cerr << " " << (int)b[i] << " ";
}
cerr << "]" << endl;
}
unsigned char const *buf_ptr = buf;
while( numbytes > 0 )
{
#ifdef WIN32
int n = ::send( socket_, (const char*)buf_ptr, static_cast<int>(numbytes), 0 );
#else
int n = ::send( socket_, buf_ptr, numbytes, 0 );
#endif
if( n<0 )
{
// BailOnSocketError definitely throws an exception so clear up heap
delete[] buf;
BailOnSocketError( "send failed" );
}
numbytes -= n;
buf_ptr += n;
}
delete[] buf;
}
The BufferedReader is not the problem specifically, and neither is 'the TCP stack [being] full'. And select() isn't required to solve it.
You are making several common mistakes here.
You are ignoring the return value of read(). It could be -1, indicating that the peer has closed the connection, which you must test for and act on first. Or it could be any value between 1 and the size you requested. You are just blindly assuming you will get 5 bytes when you call in.read(buffer,0,5). There's no guarantee of that. You need to use DataInputStream.readFully().
You are sending 8-bit chars from C++, and using a Reader in Java. This doesn't make any sense whatsoever. Use an InputStream. Specifically, a DataInputStream so you can call readFully() as suggested above.
Socket.isClosed() tells you whether you have closed the socket. It doesn't tell you whether the peer has closed the connection. That's what the -1 above is for.
Similarly Socket.isInputShutdown() tells you whether you have shutdown input on this socket. It doesn't tell you whether the peer has shutdown output at his end. Again, that's what the -1 above is for.
So both those tests are pointless, and the message you are printing when either of them is true is incorrect.
Inspect the communication with a sniffer. Wireshark is a good one.
While BufferedReader is great for file operations, it strikes me as a really bad idea to use one while reading from a Socket.
Otherwise, it might be that the BufferedReader thinks that data is still coming into the buffer when it really isn't.
I recommend removing it and dealing with the InputStreamReader directly to see if the problem still occurs.
Note that big chunks of data can be divided into several packages when sending over sockets. I wrote an answer here regarding sockets in C++, that addresses it shortly.
I see three possibilities:
Your tcp stack could be full. Thats a real bugger. You can read more about that in this article, but in short: the socket is full in some end of your socket, making the sender block more writes. You will have to read that data from the receiving side before send will unblock. You can check for "TCP ZeroWindow" with wireshark to find this. (default settings will be black with red text, you can't miss it)
It could be your sending side that is waiting for you to push more data to send
I don't think this is valid, but I guess that the receiving side could as well wait for more data to receive. As I understand it it is really up to the underlying network to decide if the data should be sent or not.
You can use select (sorry, don't know of the unix equivalent arguments, or java's) when sending data to check if you are ok to actually send (also described in my answer here).
I have the following Java socket client app, that sends same string to socket server:
import java.net.*;
import java.io.*;
public class ServerClient {
public static void main(String[] args) throws IOException {
System.out.println("Starting a socket server client...");
Socket client = new Socket("XXX.X.XXX.XX", 12001);
BufferedOutputStream stream = new BufferedOutputStream(client.getOutputStream());
String message = "ABC";
BufferedReader inputReader = new BufferedReader(new InputStreamReader(System.in));
String input = null;
while ( true ) {
System.out.print("Would you like to send a message to Server? ");
input = inputReader.readLine();
if ( !input.equals("Y") ) break;
System.out.println("Message to send: " + message);
System.out.println("Message length is: " + message.length());
byte[] messageBytes = message.getBytes("US-ASCII");
stream.write(messageBytes, 0, messageBytes.length);
stream.flush();
}
System.out.println("Shutting down socket server client...");
stream.close();
client.close();
inputReader.close();
}
}
The first time message is sent, server receives the message; however, every subsequent time I'm trying to send this message, server is not receiving anything. Message simply disappears. I am writing to the socket successfully (no exceptions) but nothing is coming on the other side of the pipe (or so I'm told).
I do not have access to the server app, logs or code, so I'm wondering if there is any approach you can recommend to figure out why server is not receiving subsequent messages. Any ideas would be greatly appreciated!
Clarification:
New lines are not expected by the server; otherwise, how would it even receive message the first time? As a trial and error, I did try sending '\n' and "\r\n" and 0x00 characters at the end of the string - all without any luck.
I thought flushing was an issue, so I tried various outputstream classes (PrintStream, PrintWriter, FilterOutputStream), but was still running into same exact issues. Then, if "flushing" is an issue, how is it working the first time?
Other tests:
1 - use a network sniffer to see what is realy hapening on the network
2 - use some program like TCP Test Tool to send data to the server and simulate your program. (netcat can also be used, but it sends a newline after each line)
Remember:
TCP is stream oriented. not message oriented.
One write on the client could take several reads on the server to .. read
Multiple writes on the client could get read by the server in one read
You'll hardly see the above scenarios in a test application on a local network, you will see them very quick in a production environemnt, or when you start to really speed up the sending/receiving.
Following this, if you are sending messages you need a delimiter, or some other way of indicating 'here's one message', e.g. defining the protocol to be 'the first byte is the length of the following message'.
And you'd need to check the receiving end wether it read a partial message, a whole message, and any combination thereof (e.e.g one read might have read 3 and a half message..).
A quick solution for your test app, write lines. That is, a string followed by a newline character. A bufferedreader's ReadLine() could then take care of the reassembly for you on the receiving end.
It works correctly here... but I am missing a carriage return or some other end of message after sending the message.
Hard to write more without knowing what the server expects (protocol)...
Maybe you should try something like
String message = "ABC\n";