I am using a Fabric 2.2 network with two organizations, one endorsing peer per organization and one ordering service.
I want to scale up my network with many clients and servers in order to test the performance of the system (latency and throughput), similarly to what it is done in this paper ieeexplore.ieee.org/iel7/69/4358933/08246573.pdf in section 6.1.2
I confuse maybe the terms. I am really new to Fabric.
What is the meaning of "clients" and "servers" in the paper? Are they ca-servers and ca-clients? In this case, how to configure a network with an increasing number of Fabric clients and servers?
I am currently migrating a switchboard asterisk from sip to pjsip
And I find something new, you can use different protocols like udp,tcp,tls,ws,wss....
I wonder what protocol is better and safer...
I understand that tls i wss are safer
Currently I only use udp and it seems that everything works fine, But I can also make it to work with every one at the same time.....
I would like you to help me understand what is the use of these protocols and if I would have to use some specific.
Regards,
TCP better if you have bad network(like 3G mobile) or complex NAT. UDP faster setup and most common.
TLS if you need encryption. WSS is for webRTC/websocket(call from browser).
While mvapich from version 2.3 deprecated the Nemesis interface, is there any way now to configure it at once for Infiniband support with fallback to TCP when failed? Or do I have to have two compilations for different network setups in my grid?
I'll answer my question with the information from MVAPICH developers:
At this point, the default MVAPICH channel cannot use TCP as a fallback if IB fails. We will see if such a support can be enabled in the future.
I'm working on a project that has server and client roles. I would like to have servers and clients automatically detecting each other. At a first glance, zeroconf seems to be the best solution. But it would add a dependency, Bonjour, to the project. I use Qt for the GUI and Qt has native support of broadcast and multicast. So I'm wondering if it's feasible to just use those features to replace zeroconf?
Here is a decent post about how zeroconf works.
I don't think I need the features of obtaining an IP Address and obtaining a Hostname from zeroconf. All I want is let one instance be aware of other instance's existence.
My current plan is combining broadcast and multicast. Each server chooses a unique multicast group and broadcast this group to the others. When a client wants to connect a to specific server, it joins the corresponding group.
Some people mention that it's normal that routers blocking local broadcast. If this is true, my plan would not be feasible.
Is there any standard way to implement this rather than using zeroconf?
Just a technical question -
Can two or more SNMP agents be run on the same port (on the same machine)?
My first instinct would be no since host:port identifies an instance of an application but I'm not sure.
Thank you!
Technically, if the OS supports it, the SO_REUSEADDR SO_REUSEPORT options may be set on a socket to allow other processes to bind to the same address/port and thus allow multiple processes to receive messages on the same address/port. But both processes would have to set the option, and I doubt any agent implementations do that because it would not make sense to do so--it would just cause headaches having both agents potentially responding to a single request. Managers won't be equipped to handle it.
However, you can instead run an SNMP proxy in the primary address/port, configured to forward requests to one of multiple agents based on query, security, or (with SNMPv3) context/engine ID parameters, and forward responses back.
Also, using AgentX, you have an SNMP master agent running on the primary address/port, and one or more SNMP sub-agents connected to the master agent. The master agent dispatches requests to the sub-agents as appropriate, merging the results into a single response, so that to the outside world it appears as a single agent. Each sub-agent typically handles a different branch of OID space (one sub-agent implementing certain module(s), another sub-agent implementing other module(s)).
But taking two agents intended to own the address/port exclusively, and forcing them to share through the REUSE options, while it may be possible, would not be wise.
You can run multiple agents on the same host and with the same port if they have differents ip address (can use a netsh script for that).
Personnaly I use the nsoftware ddl : SecureSNMP V8 edition .NET to do this.
You can look at this post : Multiple SNMP Agents with nsoftware dll
No, two agents cannot both run on the same port as seperate applications for the reasons you assumed (except with a brittle packet sniffing hack, which we'll not go into).
However, 2 agents can be accessed through the same port if there is some mechanism that handles the actual port and distributes requests based on MIB. For example the Windows SNMP service does this, allowing any number of SNMP agents to be added as "extensions" through the registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ExtensionAgents) by writing them as DLLs and using the snmp.h headers in the platform SDK.
You are correct: ports can't be shared.
If both the agents were designed by you, then the answer can be different.
Consider the HTTP and FTP cases, we can use host names to distinguise multiple sites on the same port, then why can't we do it for SNMP?
We can create a dispatcher who monitors port 161 for incoming traffic. Then use multiple real agents to handle those traffic behind. We can feel free to design how to distinguise them. Personally I prefer the FTP virtual host name manner and use | to distinguise agents.
Maybe I can create a demo for #SNMP Suite in the future.
But if you need to work with existing agents on the same server, then such flexibility is lost.