JPEG
hi, i have this code where the screen of some PC - on lan - is captured every 15 minutes, the capturing works fine, also the picture is saved on that PC with JPEG extension. i tried to write the file to socket without saving it on disk, it worked, but when the receiver gets the file - with JPEG extension - it doesnt read it, so i tried saving the file, sending it, then deleting it but it didnt work as well.
the code is:
sender side:
....
....
//
data = new ByteArrayOutputStream();
//
JPEGCodec.createJPEGEncoder(data).encode(screenShot);
//
fileOutput= new BufferedOutputStream(new FileOutputStream("Screen_Shot" + InetAddress.getLocalHost + ".jpg"));
//
data.flush() ;
//
fileOutput.flush() ;
//
byte[] b = data.toByteArray() ;
//
fileOutput.write(b) ;
fileOutput.close() ;
//
output.write(b);//socket output
//
data.close() ;
....
....
receiver side:
....
....
receivedImage = new BufferedInputStream(connection.getInputStream());
//
fileOutput= new BufferedOutputStream(new FileOutputStream("Screen_Shot" + receivedImage + ".jpg"));
# 1
Why not get rid of all that complication and encode directly to connection.getOutputStream()?Can't see all your receiving code but are you flushing and closing the output correctly?
ejpa at 2007-7-12 1:53:24 >
# 2
Does the receiver try to convert a BufferedInputStream to a string there, or am I missing something?
I think it's most likely the problem is on the receiving end. Is the file the first and last thing you read from that socket? Are you sure it really detects both the begining and the end properly?
Here's a few things to check without much effort:
-Is the file size on the receiving end as expected?
-Look at the file on both ends with a hex viewer, are they similar? Where do they defer?
-Does the file on the receiving end have a proper JPEG header at the begining? It easy to spot, since theres a small identifier that is practically in text.
# 3
hi, well, ejp, what complications are you talking about? the capture application is on each PC, captures a JPEG image every fifteen minutes, stores the captured image on its disk, then writes that image to the socket, the receiver in turn receives the encoded image JPEG, the whole capturing and writing is working properly, and the receiver gets the image with the same name, extension, size but theres nothing to read, when i open the image with any image viewer i get CANT DETERMINE TYPE, thats strange because im using the same way in both sides, on one side its working, but there's something wrong in the receiver side.
im using BufferedImage to save the image byte code as follows:
//
....
....
//
BufferedOutputStream fileOutput;
//
ByteArrayOutputStream data;
//
BufferedImage screenShot;
//
try
{
data = new ByteArrayOutputStream();
//
JPEGCodec.createJPEGEncoder(data).encode(screenShot);
//
fileOutput = new BufferedOutputStream(new FileOutputStream("Screen_Shot" + count + ".jpg"));
//
data.flush() ;
//
fileOutput.flush() ;
//
byte[] b = data.toByteArray() ;
//
fileOutput.write(b) ;
//
output.write(b); // sockets output stream, "ObjectOutputStream"
//
fileOutput.close() ;
//
data.close() ;
}
//
catch (IOException ex)
{
JOptionPane.showMessageDialog(null, "Couldn't write file to disk","Error", JOptionPane.ERROR_MESSAGE) ;
//
ex.printStackTrace();
}
//
the file is saved properly, i guess that the file is also written properly to the socket, so yes, maybe the error is in the receiver side, but im using the same code as above to save the file, but i cant get the BufferedImage to read the incoiming packet(image), im stuck here.
NOTE: the image that JPEG codec will read should be BufferedImage, right?
# 4
You don't need to use JpegCodec blah blah at all. It is nonsense and useless.
Simply follow EJP's advice. That's all you should do. Period.
public void sendScreenCapture(Socket socket, BufferedImage capture){
try{
OutputStream os = socket.getOutputStream();
ImageIO.write(capture, "JPEG", os);
os.close();
}
catch (IOException ie){
ie.printStackTrace();
}
}
Message was edited by:
hiwa
hiwaa at 2007-7-12 1:53:24 >
# 5
thanx a lot, you guys rock, one more simple question, it has nothing to do with networking, but, how can you write to and read from dll files? is that possible,i get an exception that i cant read/write to the dll file becoz another process is using that file, the code is like this:
...
...
//
File readFile = new File("something.dll");
//
if(readFile.exists())
{
int size = (int) readFile.length();
//
int chars_read = 0;
//
FileReader reader = new FileReader(readFile);
//
char[] data = new char[size];
//
while(reader.ready())
{
chars_read += reader.read(data, chars_read, size - chars_read);
}
//
reader.close();
//
String textData = new String(data, chars_read, size-chars_read);
//
list.append(textData);//some text area
//
FileWriter writer = new FileWriter(readFile);
//
writer.write("somethings");
}
//
catch(Exception ex)
{
JOptionPane.showMessageDialog(null, "Couldnt Open Black List");
//
ex.printStackTrace();
}
# 6
You can't do that.
There are some other problems here. Don't use a Reader or a Writer unless you know the data is 100% text. Otherwise use a Stream. And don't use available() as a test for EOF. That's not what it's for. And don't use a String as a container for binary data. That's not what it's for either.
ejpa at 2007-7-12 1:53:25 >
# 7
then is it possible to create a blocked ip address list or ban an ip address using java? the thing im trying to do is to block or discard incoming requests if that request has a destination ip of a blocked address on the block-list, which is a list that i can add to or remove from ip addresses.
# 8
You can get the InetAddress from the socket once it's available(promptly after the accept), check it against the IP filter, and close it if it fails the test.
As far as I know, that's as pre-emptive as you can get in java. I don't think it offers accept-testing and half-open connections.
# 9
You can also do that via SocketPermission and a security manager, but it still happens after the connection has been accepted by TCP.There's no way any application in any language can vet incoming connection request and reject them before the TCP stack accepts them.
ejpa at 2007-7-12 1:53:25 >
# 10
then it is impossible to develop a java based firewall.
# 11
Correct.
ejpa at 2007-7-12 1:53:25 >
# 12
> There's no way any application in any language can vet incoming connection request and reject them before the TCP stack accepts them.
That's OS-dependant. In Windows, for example, your claim is incorrect - it is possible to trap and filter the connection pre-emptively, using WSAAccept and SO_CONDITIONAL_ACCEPT, preventing the socket from being created, though whether this prevents a SYNACK also depends on the version of Windows used.
On most other OSs, your claim is probably correct, though.
# 13
Well my point is about the SYN/ACK part. Which versions of Windows let you prevent that from being issued?
ejpa at 2007-7-12 1:53:25 >
