I want to delete certain packets (which I don't want to be part of my new pcap file) from the wireshark file (Copy of the original pcap file) via Java code.
Is it possible to create a new pcap file with certain packets removed?
Pcap isn't a format specific to Wireshark, Wireshark just happens to be able to both perform a packet capture and save it in a pcap format, as well as process pcap files for you to view, so you could probably remove the Wireshark part of the question and just ask how to manipulate pcap files using java. This would be far easier than trying to work out how to use Java to work with Wireshark to produce the resultant packet capture.
In terms of manipulating a pcap file in Java, there are many third party libraries available that expose the pcap format, or wrappers for the pcap libraries, and I suppose in most of them there would be some way to filter the captured data and save it back to a file.
Check out http://code.google.com/p/sjpcap/ which is a simple alternative to the popular wrapper http://netresearch.ics.uci.edu/kfujii/Jpcap/doc/ both of which are able to process/filter/manipulate pcap files. The latter is more complex and potentially overkill for what you are doing.
Related
I'm studying about Networking .I had sent a file image between two pc by ICMP then capture by wireshark. I'm try to get raw data from pcap file and decode it to get data that I just had sent by java. I had taken a lot of times but I dont know how i can do it. I really wanna you do me a favor. Sorry because of English not my mother tongue.
I am writing a client-server program in JAVA in which I am sending a file from server to client.As the file size may be quite high therefore I decided to divide the file in 5 parts and then send it to the same client in 5 different Threads.
My Algorithm is to use Java Zip API and create a zip file of the file to be sent,then I will divide the Zip file into 5 parts.
The problem is that there is not method in [ZIP API][2] that could divide the file.
This is the tutorial that I am referring for sending files through Thread.
Anyone who can guide me is there anything wrong with my Algorithm Or do I have to do with different strategy?
You should separate the zipping part from the splitting part. If you have to send these to a client, you probably don't want to keep the complete zip file in memory while you wait for the client to request the next chunk... so the simplest approach would be to zip to disk first, and then serve that file in chunks. At that point, it really doesn't matter that it's a zip file at all - and indeed for certain files types (e.g. images, sound, video) you may not want to go via a zip file at all.
I would suggest you tell the client the file name and size, and then let the client request whatever section of the file it wants. It can then decide what chunk size to use: you just need to seek to the right bit of the file and serve as much data as the client has requested.
Breaking up the file isn't a ZIP function. You could create multiple byte arrays from the resulting zip file (by segmenting the array) and sending each segment in a different thread. This would be similar to what download managers of yesteryear would do.
The client would then have code to re-assemble the byte array in the correct order. You'd probably need to add some additional information to each segment like the correct sequence, the filename to be restored, and the number of segments expected.
Is it possible to download large files (>=1Gb) from a servlet to an applet using HttpClient? And what servlet-side lib is useful in this case? Is there another way to approach this?
Any server-side lib that allows you access to the raw output stream should be just fine.
Servlets or JAX-RS for example.
Get the output stream, get the input stream of your file, use a nice big buffer (4k maybe) and pump the bytes from input to output.
On the client side, your applet needs access to the file system. I assume you don't want to keep the 1GB in memory. (maybe we want to stream it to the screen, in which case you don't need elevated access).
Avoid client libraries that try to fully materialize the returned content before handing it to.
Example code here:
Streaming large files in a java servlet
I'm trying write a java program to send live microphone data over UDP, then receive the data in VLC. I'm basically using the same code as in this post to package up the stream and send them over. When I receive the data in VLC, I get nothing. I see a bunch of input coming in but none of it is interpreted as audio data. It tries to resolve the information as mpga or mpgv, but I'm pretty sure it's being sent as raw audio. Is the problem on VLC's end? Should I configure VLC to receive a specific format? Or is the problem with my program not packaging the data in a way VLC can interpret it?
First thing you should do is capture the live microphone data to a file and figure out exactly what format it is. Then transfer the file to VLC (if that makes sense) to see if VLC can cope with it in that form.
If you are going to use UDP in the long term, you need to be sure that the audio format you are using can cope with the loss of chunks of data in the middle of the audio stream due to network packet loss. If not, you should use TCP rather than UDP.
Our application is a client/server setup, where the client is a standalone Java application that always runs in Windows, and the server is written in C and can run on either a Windows or a Unix machine. Additionally, we use Perl for doing various reports. Generally, the way the reports work is that we generate either a text file or an xml file on the server in Perl and then send that to the client. The client then uses FOP or similar to convert the xml into a pdf. In either the case of the text file or the eventual pdf, the user select a printer via the java client and then the copied over file prints to the selected printer.
One of our "reports" is used for creating barcodes. This one is different in that it uses Perl to fetch/format some data from the database and then sends that to a C application that creates some Raw print data. This data is then sent directly to the printer (via a simple pipe in Unix or a custom application in Windows.
The problem is that this in no way respects the printer selected by the user in the Java client. Also, we are unable to show a preview in said client. Ideally, I'd like to be able convert the raw print data into a ps/pdf or similar on the server (or even on the client) and then send THAT to the printer from the client. This would allow me to show a preview as well as actually print to the selected printer.
If I can't generate a preview, even just copying over the raw data in a file to the Java client and then sending that to the printer would probably be "good enough." I've been unable to find anything that is quite what I'm trying to accomplish so any help would of course be appreciated.
Edit: The RAW data is in PCL format. I managed to reconcile the source with a PCL language reference guide.
Have you had a look at iText?
You willl need to find some way of interpreting the RAW format, which most likely is some printer language like PCL or HPGL into a format you can use. This is probably best done at serverside.
A java based PCL interpreter can be found at http://openpcl.sourceforge.net/ - I have no experience with it.
I figured out a way to generate the barcodes using XSL-FO directly. This is the "correct" answer based on our architecture and trying to do anything else would have been just a dirty hack.