Corda 3.1 - discovering which nodes are down and not operating - corda

I have a question regarding Corda 3.1 and using the network map for the purpose of seeing if node is up - is it generally a good idea to use it for that ?
From these notes https://docs.corda.net/network-map.html#http-network-map-protocol as there is a polling of the network map participants data (in case that our cached data expired) it should be technically possible to do that.
Could you see any drawbacks of implementing this in that way ?
If the node is configured with the compatibilityZoneURL config then it first uploads its own signed NodeInfo to the server (and each time it changes on startup) and then proceeds to download the entire network map. The network map consists of a list of NodeInfo hashes. The node periodically polls for the network map (based on the HTTP cache expiry header) and any new entries are downloaded and cached. Entries which no longer exist are deleted from the node’s cache.

It is not a good idea to use the network map as a liveness service.
The network does have an event horizon parameter. If the node is offline for longer than the length of time specified by the event horizon parameter, it is ejected from the network map. However, the event horizon would usually be days (e.g. 30 days).
Instead, you can just ping the node's P2P port using a tool like Telnet. If you run telnet <node host> <P2P port> and the node is up, you'll see something like:
Trying ::1...
Connected to localhost.
Escape character is '^]'.
If the node is down, you'll see something like:
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host
Alternatively, if you want to check liveness automatically from within a flow, you can define a subflow like the one below. This flow will return a boolean indicating whether a given party on the network is offline.
#InitiatingFlow
class IsLiveFlow(val otherPartyName: CordaX500Name) : FlowLogic<Boolean>() {
#Suspendable
override fun call(): Boolean {
val otherPartyInfo = serviceHub.networkMapCache.getNodeByLegalName(otherPartyName)!!
val otherPartyP2PAddress = otherPartyInfo.addresses.single()
return try {
Socket().use { socket ->
socket.connect(InetSocketAddress(otherPartyP2PAddress.host, otherPartyP2PAddress.port), 1000)
true
}
} catch (e: IOException) {
false
}
}
}

Related

Check whether there is an Network connection available on pure dart

Is there a way in dart to get notified (listen to) when the network disconnecting and do action only if it off?.
I do not want to check internet connection so no need for pinging google.com (connection to router without internet is still good).
Searching for simple way that interact with the network interfaces of the device and listen to change or return True/False about the network state.
In worse case I can use Process.run(...) with bash commend but this ugly fix.
No flutter here only pure dart (dart Console Application).
If you are running the program on linux you can use bash commend like this
// Check if connected to network, if there is a connection than return network name
Future<String> getConnectedNetworkName() async {
return await Process.run('iwgetid',
['-r']).then((ProcessResult results) {
print(results.stdout.toString());
return results.stdout.toString().replaceAll('\n', '');
});
}
This will return network name even if the network does not connected to the internet

Is it possible to restrict ForceBindIP to only inbound/outbound traffic?

I'm using ForcebindIP to point an app at a specific network adapter, like this:
forcebindip -i 192.168.0.5 MyCSharpApp.exe
This works fine and the app isn't aware (or doesn't access) any of the other network adapters on the PC.
Is it possible to restrict ForceBindIP to outbound traffic only leaving the app to receive data from any local network adapter? Or even to specify a network adapter for outbound and another for inbound traffic?
I can't find an extra startup parameter for ForceBindIP that does this.
I'd appreciate any help with this.
If I get your problem correctly, you want to bind your application to listen for packets on all available interfaces but return packets to only through one given interface. I also assume it's a server application and you don't have neiter source code nor control over its behaviour.
Disclosure: I do not know how ForceBindIP works internally, I'm basing my understanding of it on this passage from the website:
it will then inject a DLL (BindIP.dll) which loads WS2_32.DLL into memory and intercepts the bind(), connect(), sendto(), WSAConnect() and WSASendTo() functions, redirecting them to code in the DLL which verifies which interface they will be bound to and if not the one specified, (re)binds the socket
Problems to overcome
I don't believe your desired configuration is possible with just one application level DLL injector. I'll list a few issues that ForceBindIP will have to overcome to make it work:
to listen to a socket, application has to bind() it to a unique protocol-address-port combination first. An application can bind itself to either a specific address or a wildcard (i.e. listen on all interfaces). Apparently, one can bind to wildcard and specific address simultaneously as outlined in this SO question. This however will be two different sockets from the application standpoint. Therefore your application will have to know how to handle this sort of traffic.
When accepting client connection, accept() will create a new socket and parameters on that are managed by Windows, I don't believe there's an API to intercept binding here - by this time the connection is considered established.
Now imagine, we somehow got a magic socket. We can receive packets on one interface and send to another. The client (and all routing equipment on the way) will have to be aware that two packets originating from two different source IP addresses are actually part of the same connection and be able to assemble the TCP session (or correctly merge UDP streams).
You can have multiple gefault gateways with different priorities and rules (which is a whole different topic to explore) but as far as I'm aware that's not going to solve your particular issue: majority of routing protocols assume links are symmetric and expect packets to keep within same interface. There are special cases like asymmetric routing and network interface teaming but they have to be implemented on per-interface level.
One potential solution
One way to achieve what you're after (I don't know enough about your environment to claim it will work), will be to create a virtual interface, set it into yet another IP network, bind your application to it, then use firewall (to, say, allow multicast backets into the "virtual" network) and routing from that network to required default gateway with metric set to 1. I also suspect just any Windows will not be that flexible, so you might need like a Server Edition.
I am sorry this didn't turn out to be the ready-to-fly solution, I however am hoping this gives you more context to the problem you are facing and points you into other directions to explore.
You can use Set-NetAdapterAdvancedProperty command in Powershell to set the flow control of your specified adapter
To get the names and properties of all the network adapter :-
Get-NetAdapterAdvancedProperty -Name "*"
Suppose you want the network adapter named "Ethernet 2" to be only used to receive data from internet then type :-
Set-NetAdapterAdvancedProperty -Name "Ethernet 2" -DisplayName "Flow Control" -DisplayValue "Rx Enabled"
You can find more in :
https://learn.microsoft.com/en-us/powershell/module/netadapter/set-netadapteradvancedproperty?view=win10-ps
Microsoft winsock example has a usage in their example for limiting a socket to only send or receive mode. It might help.
https://learn.microsoft.com/en-us/windows/win32/winsock/complete-client-code
Outbount and Inbount limits are not imposed while binding. But latter or when connection is established.
Line of code pertaining to this in client code is toward the end.
// shutdown the connection since no more data will be sent
iResult = shutdown(ConnectSocket, SD_SEND);

What is the difference between a 'shallow' and 'deep' ping?

So as a fairly new (out-in-the-world-working) developer I'm not unfamiliar to the concept of pinging as it was taught to me in uni and I've used it in various small assignments I've encountered before.
My understanding of it is determining whether another host is present and responsive on a network.
I've implemented in Java (the language i'm most comfortable in) some code similar to the one below when wanting to achieve pinging:
try {
String ip = "127.192.199.01";
InetAddress inet = InetAddress.getByName(ip);
System.out.println("Send ping-request to: " + ip);
if (inet.isReachable(5000)){
System.out.println(ip + " is reachable.");
} else {
System.out.println(ip + " NOT reachable.");
}
} catch ( Exception e ) {
System.out.println("Exception:" + e.getMessage());
}
However I pretty new to the concept of 'shallow' and 'deep' pinging which is something I've encountered at my current workplace.
So far though I've been able to figure out that deep pinging is basically about testing that all connections are alive and working while testing functionality through as much of a webstack as possible.
Got that from: what is deep_ping
My question is:
What does a shallow ping do then?
And what is then the main difference (if any) between a shallow and deep ping?
Shallow ping works by sending one or more (ICMP/ICMP6) Echo Request packets to the host and only tests if the network is working i.e. if the host is reachable from your machine.
Deep pinging works by testing the application. How the deep ping is implemented is up to the developer but it could be via a "status" endpoint which responds with the current application status, or another similar interface (as described in the link you already mentioned).
As per your link, deep pinging can also mean testing an entire subnet or testing other protocols than the standard Echo Request.
This sounds like you are performing host availability test on different OSI layers (https://en.wikipedia.org/wiki/OSI_model)
A ping how you know it is performed on the transport layer, where a single packet is sent to the other machine and the OS responds with another packet.
In that case you do not know if there is ANY application running on that node other than the clean OS.
Going further up in the OSI layers you can then perform tests on you business logic like calling APIs of your HTTP based REST API
My gut feeling is that "shallow ping" means a ping performed using the standard ICMP request (the well known ping command we know about), a "deep ping" is trying to access the actual remote service by opening a socket on a given port and see if you get any answer
How I can interpret it:
Shallow ping : The host is available, port on which service is exposed is accepting. (more like telnet)
Deep ping : You are actually hitting one of the service and getting an expected response back.
Again, these are more like custom terms, not an actually defined standard.

what causes the data power object to goto pending state and how can it be resolved?

In datapower, the operational state of queue manager object is pending. The information provided for this operational state is as follows : "This message indicates that the configuration of the object has changed, but has not been committed and has yet to take effect. No user intervention is required." What is exactly causing this problem and how can this be resolved?
If it is "pending" for a MQ QM object it means that DataPower is trying to figure out if it has a connection to it or not.
Normally if a QM object is in "pending" for a while, more than 20 seconds, it would mean that it didn't get the connection.
Check the System log and you'll probably see a ton of connection errors to the QM server.
First go to Troubleshooting from the Control Panel and do a TCP test to make sure you have a connection to the MQ server using the IP and port of the listener on the QM.
If you get a connection then check the MQ logs for any authentication issues, eg. user and/or auth-records. You need a Server-Connection channel for DataPower!
If you don't get a connection in TCP test then check your firewalls and also make sure that the DataPower network is setup correctly if you have multiple network cards (NIC) setup and set a static route for the MQ on the correct NIC.

HTTP Error: 400 when sending msmq message over http

I am developing a solution which will utilize msmq to transmit data between two machines. Due to the seperation of said machines, we need to use HTTP transport for the messages.
In my test environment I am using a Windows 7 x64 development machine, which is attempting to send messages using a homebrew app to any of several test machines I have control over.
All machines are either windows server 2003 or server 2008 with msmq and msmq http support installed.
For any test destination, I can use the following queue path name with success:
FORMATNAME:DIRECT=TCP:[machine_name_or_ip]\private$\test_queue
But for any test destination, the following always fails
FORMATNAME:DIRECT=$/test_queue
I have used all permutations of machine names/ips available. I have created mappings using the method described at this blog post. All result in the same HTTP Error: 400.
The following is the code used to send messages:
MessageQueue mq = new MessageQueue(queuepath);
System.Messaging.Message msg = new System.Messaging.Message
{
Priority = MessagePriority.Normal,
Formatter = new XmlMessageFormatter(),
Label = "test"
};
msg.Body = txtMessageBody.Text;
msg.UseDeadLetterQueue = true;
msg.UseJournalQueue = true;
msg.AcknowledgeType = AcknowledgeTypes.FullReachQueue | AcknowledgeTypes.FullReceive;
msg.AdministrationQueue = new MessageQueue(#".\private$\Ack");
if (SendTransactional)
mq.Send(msg, MessageQueueTransactionType.Single);
else
mq.Send(msg);
Additional Information: in the IIS logs on the destination machines I can see each message I send being recorded as a POST with a status code of 200.
I am open to any suggestions.
The problem can be caused by the IP address of the destination server having been NAT'ed through a Firewall.
In this case the IIS server receives the message okay and passes it on to MSMQ. MSMQ then reads the message and sees the destination of the message as being something different than the known IP addresses of the server. At this point MSMQ rejects the message and IIS returns a HTTP status 400.
Fortunately the solution is fairly straightforward. Look in %windir%\System32\msmq\mapping. This folder can contain a bunch of xml files (often sample files are provided) that each contain mappings between one address and another. The name of the file can be anything you like, here is an example of the xml formatted contents:
<redirections xmlns="msmq-queue-redirections.xml">
<redirection>
<from>http://external_host/msmq/external_queue</from>
<to>http://internal_host/msmq/internal_queue</to>
</redirection>
</redirections>
The MSMQ service then needs restarting to pickup the new configuration, for instance from the command line:
net stop msmq
net start msmq
References:
http://blogs.msdn.com/b/johnbreakwell/archive/2008/01/29/unable-to-send-msmq-3-0-http-messages.aspx
http://msdn.microsoft.com/en-us/library/ms701477(v=vs.85).aspx
Maybe you have to encode the $ as %24.

Resources