We Keep Coding

How to use zeroMQ in Desktop application

I am working in a desktop application, where application is deployed in both windows and mac platforms. As part of the application, it should communicate with native layer. Currently the communication between native layer and Java layer is done using sockets. Recently some one in the team suggested to use zeroMQ. Can any one of you guys please clarify my doubts.
How zeroMQ better than sockets
Is it possible to install zeroMQ library as part the Desktop client installation
I gone through the link 'https://github.com/zeromq/clrzmq4', it given libraries specific to amd64 and i386 processor family. Do I need to build it separately from the source code for different processors?
Do I still require .dll files to use zeroMQ in Java?
Do I require Visual studio to build zeroMQ libraries in windows (Since my native layer written in C#, my C# application communicate with zeroMQ socket socket written java)?

How zeroMQ better than sockets
http://zeromq.org/topics:omq-is-just-sockets
Is it possible to install zeroMQ library as part the Desktop client installation?
Yes, you need to build the libraries depends on the processor and embed them in your application.
Do I need to build it separately from the source code for different processors?
Yes, you need to build the libraries from source. zeroMQ is processor centric.
Do I still require .dll files to use zeroMQ in Java?
Yes, Following link may help you
Exception in thread "main" java.lang.UnsatisfiedLinkError: ... \jzmq.dll: Can't find dependent libraries
Do I require Visual studio to build zeroMQ libraries in windows?
Yes
This link may help you to get basic examples.

Regarding ZeroMQ in a desktop application on Windows talking to another process on the same machine, bear in mind that zmq_ipc is not supported (see zmq_ipc(7)). Or at least, that's the last I heard. This is because it's fundamentally impossible to implement anything like quite like select() or epoll() for named pipes in Windows. Just use zmq_tcp instead.
The same basic problem plagued the development of the select() implementation in Cygwin and its derivatives. They got round the problem by starting a thread for every non-socket file descriptor (i.e. named pipes, serial ports, etc) being selected, with each thread polling the HANDLE for whether any data had arrived (or whatever events were being set in select()). Not very efficient. Yeurk.
Proactor vs Reactor
Windows is proactor (which can do only proactor), everything else (*nix, VxWorks) is reactor (which can also be used to implement a proactor). The development of the boost.asio library for C++ was influenced by this, and is a proactor design as a result so that it could be run on Windows. RabbitMQ is proactor too.
ZeroMQ with zmq_poll() is reactor.
Proactor - you pro-actively start up an asynchronous routine to handle whatever turns up in the future.
Reactor - you react to the arrival of whatever has turned up by starting a synchronous call to whatever routine you wish to handle it knowing that it will complete very quickly because the data is already there.
The difference is key. In a proactor design, once you have started up that asynchronous routine to read a message, you cannot (easily) stop it or change it until it has done its thing. That is very annoying if you change your mind, for example as a result of reading some message from somewhere else.
Small caveat - Windows does support select() for network sockets (thus reactor programming is possible with network sockets, but only network sockets), and is the only reason why ZMQ is supported to any extent whatsoever on Windows.
Mixing ZMQ with Desktop Application Event Callbacks
Anyway, proactor means that Windows and C# fundamentally expects everything to be served by callbacks. This basically means you won't be using the zmq_poll() call to tell you if new messages have arrived if you also have callbacks handling GUI events. Instead you'd most likely be making asynchronous calls to zmq_revcmsg(). Trying to mix zmq_poll() in with callbacks is asking for trouble (you'd be blending proactor and reactor).
Message Formats
ZeroMQ and sockets both transfer bytes (as discrete messages with ZeroMQ, as a byte stream with sockets). One still has the challenge of deciding what the bytes mean to applications.
I can recommend using something like Google Protocol Buffers to serialise messages for transport by ZeroMQ. It's available for both C# and Java, but it doesn't demarcate message boundaries. Fortunately, ZeroMQ does. [Using GPB over a socket stream can be painful, you have to demarcate the message boundaries oneself]. So you can serialise a message to a buffer, hand the buffer over to ZeroMQ as a message, the recipient receives the message and knows for absolute certain that there is one single solitary GPB within. If you like you can use GPB's "oneof" to smuggle arbitrary message types across, which can be very liberating. You can accomplish the same with other serialisation technologies too of course, my personal favourite being ASN.1.

Stable alternative to RXTX

After using RXTX for a number of different projects, I've come across many annoying discrepancies and issues that can only sensibly be put down to bugs in the library - deadlocks, race hazards, and monitor threads deep in the RXTX library being left open preventing the program from closing (even though all ports I was using have been closed!) Running the latest "unstable" version has helped a bit, but it's still far from where I'd call it reliable, and activity on the project seems rather low at present.
However, searching for free cross-platform alternatives to RXTX doesn't seem to come up with much else.
Is there another library that anyone's tried with more luck? I don't need parallel port support, just serial, and it doesn't necessarily have to be compatible with RXTX or the javax.comm API.

We have moved to java-simple-serial-connector which seems to be very stable and comfortable at the current release 0.9.0. For now, it works on windows and linux systems. We use it for modem interactions.

There's jSerialComm too.
Serial communication in Java is a mess. I've had trouble with jSSC with a virtual usb serial on linux, but with serial-comm it connected.
RXTX is a mess.
At least I think that now this SO question has all of the worth mentioning serial communication java libraries.

There's a few of them out there now, now that Arduino is pretty popular.
There's Serialio
and PureJavaComm, but it's pretty early on in development from what I can see.
it really depends on what your needs are. RXTX has been ported pretty much everywhere, so it is widely available.

One of the issues of RXTX I faced was the delay closing the port. When checking with setserial the port configuration I discovered a parameter closing_delay=3000. This means that the port closes 3 sec after the close() method was executed. Resetting the closing_delay toany value is ignored by RXTX. RXTX insists in 3sec delay.
the JSSC library performed to our satisfaction

Serialio lib is $49/platform/developer seat which gets you unlimited distribution in unlimited apps so not too pricey. The Mac library has been stable and reliable for us in an undemanding application and availability/compatibility has been good throughout for the various Mac platforms and OS/X releases.

I use socat configured to serve a socket for a serial port.
The downside is that baud rate etc. is given to the socat invocation, it is not something you can readily alter from your program.
On the upside is I can connect across a network without anything more than changing the IP address I connect to.

jSerialCom is good !
'https://github.com/Fazecast/jSerialComm'
And here is its' wiki page： https://github.com/Fazecast/jSerialComm

Resources to accessing a S7 Profinet PLC (1212C) from Java

I have a relatively special question here. At least I think it's special as Google didn't seem to be able to provide me with the information I was looking for.
I have recently purchased a S7 Starter Kit, containing a S7 1212C PLC. It's all setup and running.
What I would like to do, is to write a Java Program (without native libraries) that communicates with that controller. I know there are the S7 Java Beans, but these seem to work only with the 200/300/400 Sieries. Are there any (open-source) implementations of Java protocol-stacks, that allow to access such a PLC from Java? If not, I would be really glad to get some pointers to some specifications that would allow me to implement a rudimentary stack myself (It seems the Web is filled with high-level information, but there seems to be very little low-level stuff around :-()
Help greatly appreciated,
Chris

There is a beta tester only Java version of libnodave, but I don't know if 1212 is supported.

In order to be able to close this. There is no pure Java way to actually use ProfinetIO the problem is that initiating the Communication is not an issue and polling values is also possible, but in order to initiate a normal Profinet IO communication I would have to access the IP stack below TCP and UDP which Java does not allow. Unfortunately the "real time" state information sent by the plc is sent using an IP frame type Java does not support.

The S7-1200 and S7-1500 series are capable of communicating via ModbusTCP (see https://www.dmcinfo.com/latest-thinking/blog/id/8869/using-an-s7-1200-plc-as-a-modbus-tcp-slave).
There's a Java library to communicate via ModbusTCP: http://jamod.sourceforge.net (haven't tried it yet).
Maybe this combination will work for you.

I don't know if this is helpful for you, but we have a java library (LGPL 3.0) which talks natively via TCP/IP with S7 devices.
have a look at http://openscada.org
The code itself can be found at http://git.openscada.org/?p=org.openscada.atlantis.git;a=tree;f=org.openscada.da.server.dave;hb=HEAD

Check out Moka7: it's an implementation of the S7 protocol in Java.

Any better options than porting from C# to Java?

I have an existing library written in C# which wraps a much lower-level TCP/IP API and exposes messages coming down the wire from a server (proprietary binary protocol) as .NET events. I also provide method calls on an object which handles the complexities of marshalling convenient .NET types (like System.DateTime) down to the binary encodings and fixed-length structures that the API requires (for outgoing messages to the server). There are a fair number of existing applications (both internally and used by third parties) built on top of this .NET library.
Recently, we've been approached by someone who doesn't want to do all the legwork of abstracting the TCP/IP themselves, but their environment is strictly non-Windows (I assume *nix, but I'm not 100% sure), and they've intimated that their ideal would be something callable from Java.
What's the best way to support their requirements, without me having to:
Port the code to Java now (including an unmanaged DLL that we currently P/Invoke into for decompression)
Have to maintain two separate code-bases going forwards (i.e. making the same bug-fixes and feature enhancements twice)
One thing I've considered is to re-write most of the core TCP/IP functionality once into something more cross-platform (C / C++) and then change my .NET library to be a thin layer on top of this (P/Invoke?), and then write a similarly thin Java layer on top of it too (JNI?).
Pros:
I mostly spend my time writing things only once.
Cons:
Most of the code would now be unmanaged - not the end of the world, but not ideal from a productivity point of view (for me).
Longer development time (can't port C# sockets code to C / C++ as quickly as just porting to Java) [How true is this?]
At this point, the underlying API is mostly wrapped and the library is very stable, so there's probably not a lot of new development - it might not be that bad to just port the current code to Java and then have to make occasional bug-fixes or expose new fields twice in the future.
Potential instability for my existing client applications while the version they're running on changes drastically underneath them. (Off the top of my head I can think of 32/64 bit issues, endianness issues, and general bugs that may crop up during the port, etc.)
Another option I've briefly considered is somehow rigging Mono up to Java, so that I can leverage all of the existing C# code I already have. I'm not too clued up though on how smooth the developer experience will be for the Java developers who have to consume it though. I'm pretty sure that most of the code should run without trouble under Mono (bar the decompression P/Invoke which should probably just be ported to C# anyway).
I'd ideally not like to add another layer of TCP/IP, pipes, etc. between my code and the client Java app if I can help it (so WCF to Java-side WS-DeathStar is probably out). I've never done any serious development with Java, but I take some pride in the fact that the library is currently a piece of cake for a third-party developer to integrate into his application (as long as he's running .NET of course :)), and I'd like to be able to keep that same ease-of-use for any Java developers who want the same experience.
So if anyone has opinions on the 3 options I've proposed (port to Java & maintain twice, port to C and write thin language bindings for .NET and Java or, try and integrate Java and Mono), or any other suggestions I'd love to hear them.
Thanks
Edit: After speaking directly with the developer at the client (i.e. removal of broken telephone AKA Sales Department) the requirements have changed enough that this question no longer applies very well to my immediate situation. However, I'll leave the question open in the hopes that we can generate some more good suggestions.
In my particular case, the client actually runs Windows machines in addition to Solaris (who doesn't these days?) and is happy for us to write an application (Windows Service) on top of the library and provide a much more simplified and smaller TCP/IP API for them to code against. We will translate their simple messages into the format that the downstream system understands, and translate incoming responses back for them to consume, so that they can continue to interface with this downstream system via their Java application.
Getting back to the original scenario after thinking about this for a couple of weeks, I do have a few more comments:
A portable C-based library with different language bindings on top would probably be the way to go if you knew up front that you'd need to support multiple languages / platforms.
On *nix, can a single process host both a Java runtime and a Mono runtime simultaneously? I know in earlier versions of .NET you couldn't have two different .NET runtimes in the same process, but I believe they've fixed this with .NET 4? If this is possible, how would one communicate between the two? Ideally you'd want something as simple as a static method call and a delegate to raise responses with.
If there's no easy direct interface support between Java & Mono (methods & delegates, etc.), one might consider using something like ZeroMQ with Protocol Buffers or Apache Thrift as the message format. This would work in-process, inter-process and over the network because of ZeroMQ's support for different transports.

Spend more time getting the requirements nailed down before deciding on an implementation. Until you know what is required, you don't have any criteria for choosing between designs.
If it's a non-windows environment, it doesn't make sense to have .NET anywhere in there, for example.

If you need something that runs on the Java Virtual Machine but looks a lot like C#, you should check out Stab. This will not help you with P/Invoke and the like but you may find it less work to port your C# code to Java and maintain it.
You should look into Mono though. I expect that all your C# code would run unmodified (except the parts that touch the unmanaged DLL).
I have not used it but jni4net is supposed to allow calling .NET code from Java. If your clients want a Java interface, this may be a solution.
I use Mono on Linux and the Mac all the time even when .NET compatibility is not a priority. I like C# and the .NET libraries and prefer the CLR to the JVM. Mono is MIT/X11 licensed which means that you can use it commercially if you like. Unlike some others, I see no reason to avoid technology championed by Microsoft while favouring technology championed by Oracle and IBM.
Using Mono will not help you with the unmanaged bits, although you can still P/Invoke into a native DLL. You will just have to port that DLL yourself or find some equivalent.
You may also want to look into Mono Ahead of Time compilation.

Have you considered mono? It would most likely support your existing code in the non-windows environment. The trick would be calling it from java, but the mono folks might have something to help you out there, too.

This probably isn't the right solution in your case, but for completeness:
There are a few languages that can target both the JVM and .NET, in particular Ruby (JRuby and IronRuby) and Python (Jython and IronPython). Scala might eventually get there too, although right now the .NET version is a long way behind the JVM version.
Anyway, you could potentially rewrite your library in Ruby or Python and target both runtimes.

If what you really, really want is to be able to code in .NET and have it run on the JVM, you could check out Grasshopper (2015-09: link possibly dead). That is what it is designed to do.
I know the Mainsoft guys have been contributors to Mono over the years. If I remember correctly, they wrote the Visual Basic compiler for Mono.
There is also the C# to Java converter from Tangible. I have heard good things but I have never used it myself.
Also, it does not help your situation much but I should point out Mono for Android.
Mono for Android runs the CLR and the Dalvik VM in parallel. In other words, the C# code you wrote for Android can be calling into Java libraries (like the Android UI for example) and executing as a single app. You had asked about the ability to run .NET and Java code in the same process. Clearly, it can be done.

One thing I've considered is to re-write most of the core TCP/IP functionality once into something more cross-platform (C / C++) and then change my .NET library to be a thin layer on top of this (P/Invoke?), and then write a similarly thin Java layer on top of it too (JNI?).
That's a possibility. On the Java side, you should consider using JNA rather than JNI. (If you use JNI, the C / C++ code needs to be written to use JNI-specific signatures.)
Another possibility is to replace the proprietary binary protocol with something that "just works" with multiple programming languages. This is the kind of problem space where CORBA and similar technologies provide a good solution.

Packet Capturing/Latency time in java

I am looking for HTTPS packet capturing code in java . But i am getting procedure for HTTP. As per our requirement we need HTTPS packet capturing code. Can anybody give me the link for that or would tell me where can I find it?.

jNetPcap might be what you're looking for: it is a java wrapper around the native libpcap library that sarnold mentions. From the basic capture example provided, it seems that it would be fairly straightforward to write a PcapPacketHandler to time the arrival of packets on an HTTPS stream.
It will, however, add native dependencies to your project, which will complicate packaging up your software.

I would suggest starting with libpcap (or its sibling, winpcap on Windows), and then interpreting the saved captures; the libpcap team has done a fantastic job making a very reliable and fast mechanism to interface with the kernel's raw sockets support to run as efficiently as possible. (The Linux kernel provides a BPF-like interface for specifying which packets to offload to userspace; see Documentation/networking/filter.txt for Linux details.)