I use ZeroMQ's C interface to distribute computation among several machines. Locally, everything works as expected with tcp://localhost:5555. However, when running client and server on two machines A and B, the request and reply only works when the server is running on A and client is running on B. If it's the other way around, only the request is received on B and the client on A never receives the reply.
To verify, that I setup everything correctly, I compiled the first example from the ZeroMQ guide but there is the same problem.
What could be the cause of this behaviour?
The problem is most likely caused by two incompatible versions of 0MQ.
This is a known problem with 0MQ v3.0.x, 3.1.x, 3.2.0, 3.2.1. These versions all used an undocumented, incompatible version of the protocol (with no version number, so very hard to get interoperating), which was finally fixed in 3.2.2 stable. If you're running the older version, and this may have come with the language binding you're using, upgrade it. If there are serious reasons why you cannot upgrade, e.g. you have clients in the wild who are using the older versions, ask on the zeromq-dev list, someone may be able to help. For what it's worth, the protocol now has version numbers, and is backwards compatible with previous stable releases (2.2 and 2.1).
Related
I have an adaptec 6805e RAID controller and I'm looking to compile the linux driver for ubuntu 20.04 (kernel=v5.4) but there have been a vast number of changes between kernel ~4x => 5x and I'm not a kernel developer.
OS:
Ubuntu LTS 20.04
Kernel:
v5.4
Adaptec 6805e:
https://storage.microsemi.com/en-us/support/raid/sas_raid/sas-6805e/
Any obvious major hurdles, or advice is appreciated, but right now the issue I'm having is trying to find a replacement for the 'pci_set_dma_max_seg_size' function. I have found the 'dma_set_max_seg_size' but that function accepts a generic device structure (struct device), whereas the adaptec code is using the (struct pci_dev) structure that seems to be specific for PCI devices.
aacraid-1.2.1-52011/linit.c:3992:10: error: implicit declaration of function ‘pci_set_dma_max_seg_size’; did you mean ‘dma_set_max_seg_size’? [-Werror=implicit-function-declaration]
3992 | error = pci_set_dma_max_seg_size(pdev,
Like I said any help is appreciated and if this seems like the wrong way to resolve this problem I'm open to ideas -- I'd like to be able to utilize the benefits of more recent linux developments with a slightly older adaptec chipset.
Thanks
Reference materials:
https://elixir.bootlin.com/linux/v5.4.128/source/include/linux
I believe since Linux v4.x you fell victim to (or benefitted from, depending on your perspective) an effort to overhaul the DMA unmapping support. That patchset, and particularly the specific patch linked to here, show what PCI driver maintainers who were obliged to accommodate this rework were expected to do:
[3/3] PCI: remove pci_set_dma_max_seg_size
Fortunately for you, they gave specific examples of how existing drivers got patched and it's not bad. It should be pretty straightforward for you to figure out at least roughly the Linux version this change corresponds to around the 2018-19 date of the patch's acceptance upstream, code a new stanza in the Adaptec driver source to update it accordingly (e.g.
#if ((LINUX_VERSION_CODE > KERNEL_VERSION(5,1,0))
<patch Adaptec's code to use dma_set_max_seg_size() here>
#else
compile the driver and be on your way. Note that the README does not explicitly mention support for the Adaptec 6805e RAID controller yet, so if you manage to make it work and post your patch you should at least add a comment to the effect that you believe this supports the controller now.
I am wondering about the limitations of using libraries in code name one. Specifically, I would like to use a specific http client library that uses nio but I am not sure if that will even work in code name one. There is an http1 client and an http2 client here
https://github.com/deanhiller/webpieces
Can the nio stuff actually be compiled into iOs? or does it have to be synchronous socket http client implementations?
thanks,
Dean
It won't work and you can't. This article is from 2016 but it's still mostly accurate. The gist of it is that most of these APIs aren't essential and if we add all of them performance/size would balloon to huge numbers.
E.g. a Codename One application can weigh less than 3mb for iOS production builds with 32 and 64 bit support. Our closest competitors clock at 50mb for the same functionality with only 64bit support. This isn't just a matter of size, it's a matter of quality (QA), maintenance etc.
This also reduces portability as we have to test this on all ports including iOS, UWP, Web etc.
Having said that we're open to adding things and have added some features to the core since the publication of that article. But either way, you can't just use an arbitrary jar and need to use a cn1lib.
Has anyone got VOLTTRON running on OS X? I'm trying to assess the effort required to make this happen.
It seems that inotify would need to be replaced with something based on FSEvents. Use of inotify appears to be limited to the volttron.platform.utils.watch_file method so it shouldn't be too difficult.
VOLTTRON does start up without error if I comment out the inotify reference but whatever is dependent on watch_file is certainly not going to work. Are there other libraries or behaviors that would be different or unavailable on OS X? I'm not concerned about hardware/driver interfaces. I don't intend to deploy on OS X but it would be nice to be able to develop on it.
Up until about two years ago we had a developer who was working in OSX and would kindly point out whenever we broke something in his environment.
We haven't really tried it since.
The two places we watch files is for authorization changes at run time. Those features will still work they just won't update state at runtime.
I don't know of any other libraries we use that would stop you from working in OSX.
I have the requirement of altering packets as a part of my University's research project and came across two libraries. which are libnetfilter_queue and libipq which is the deprecated version. libnetfilter_queue documentation is next to zero on packet alteration and the only good documentation I came across is done via libipq.
Thus, when I run my code I get the error passer: Unable to create netlink socket: Protocol not supported which I found out that is due to the fact that libipq is not supported in the new linux kernels.
My query is, is there a work around to make libipq work with Ubuntu 12.04 LTS or any reference to documentation or tutorials that would help implement packet alteration via libnetfilter_queue.
I was at this for some days and could not find solution. you help will be very much appreciated. :)
Thank you very much :)
P.S: the question is also posted over here ( https://askubuntu.com/questions/430234/libipq-not-supported-in-ubuntu-12-04-lts )
Once the ip_queue module is gone, then you can't use libipq, as it leverages that module directly; so no, there's no workaround unless you install an older kernel that still has the ip_queue module.
That said, you've mentioned absolutely nothing about what you've actually tried. If you start from a basic libnetfilter_queue example, when you're setting the verdict, you should be using nfq_set_verdict, passing in the data_len and buf parameters containing the swizzled packet data.
On the netbeans that I am using, I cannot do a basic thing such hovering the mouse over a variable and getting its type as shown in the below picture.
How can I obtain this behaviour?
On my system there is windows XP, Netbeans 6.1 and my application is a Vega7000 Application
Why are you using such an old version? It may well be a bug or simply a missing feature.
So answer is, upgrade!
https://netbeans.org/downloads/
If you need the old version for release builds, you can perhaps still do the actual development and debugging using a newer and shinier version.
Also, if you are not using one yet, use source control! I prefer git, but this is very subjective, other DVCS are good too. And note that so called distributed VCS works extremely well locally inside one source tree directory, it does not have to be distributed to many places. When working with old fragile complex code you are afraid of breaking, very frequent local commits, and diffing to known-good versions when problems arise are life savers. If you care about publishing work in progress, at least git (presumably all DVCS) allow squashing multiple commits into one before pushing to non-personal repo or branch.