How to use hyperledger network cards locally - hyperledger-composer

On Playground (macOS) I have one network card admin#perishable-network and I can connect to the business network. However the network card is not visible in directory /Users//.composer/cards. Instead I can see PeerAdmin#hlfv1 there.
Another problem is that I get an error running composer-rest-server using PeerAdmin#hlfv1: No business network has been specified for this connection

I'm guessing on playground you created the business network on the Web Browser Connection which means all cards for that business network will be held in your browser local storage not on your file system. Also that business network is running inside your browser, not in a real fabric so you cannot interact with it any other way except through playground (for example you cannot try to connect the rest server to it).
You cannot use PeerAdmin#hlfv1 with the rest server. This is a fabric network card (ie you use it to perform fabric level activities such as install, start, upgrade) not a business network card. You need a business network card (one that has been associated with a business network) in order for the rest server to connect and discover the specific business network in order to generate the rest api.

Related

Remote Access Windows IoT core device over the internet

I am working with Windows IoT core on a Gateway to Run some Edge services, all the ways to connect to the IoT core device is locally, so basically you have to be on the same network, Any possible way to access the device via the internet?
It is a generic network question. There are a two options, depending if this is for private or commercial grade use.
Configure 'port forwarding' on your router.
Using cloud service which have a published IP address. Your device 'publish' on a known location and your clients access a known place. For example, you can use Microsoft Azure IoT Hub. The purpose of remote connection is nothing more than managing the device. You can use Azure IoT Device Management.

Socket.io app not working on other devices when ran from server

I have built a socket.io app which I have ran continously using the forever command from SSH.
I am a university student and I have done this in the university. I can go onto the website / socket.io app using any computer in the university, however I cannot use my mobile phone or personal computer to access the site.
When I try and access the site, it takes about a minute to try and access the site, but then it just says "this site cannot be reached".
Is there a way I can access the site from any device? As I said, the script is running continously so there is no issue with that...
It sounds like your server is not on the public internet. Instead, it's on your university network and when you get on a device that tries to access it from the public internet, then the university firewalls won't allow it to be reached and/or the IP address you are using to access the server is not a public IP address.
When on the university network (as WiFi, for example), some universities also have multiple classes of devices on the network. Some are allowed to access any resources on the network. Others are only allowed to access public resources on the university network or resources on the internet. It could be that the computers in the university have the right privileges and it could be that your mobile phone or laptop do not, even if they are on the university WiFi.
Though there are several different ways to fix this, the usual approach is to deploy your server outside the university network in a place that it can be accessed from anywhere on the public internet (typically a hosting provider that supports the features your server needs). And, to reach your server, you would set up a DNS entry such as myplayserver.com that points at the public IP address of your server.

Site-to-site VPN vs point-to-site VPN

I have a scenario where I have a Windows VM in windows Azure that needs to connect to an external customer network (and connect to a database that is not in Azure).
This traffic is uni-directional in that it is only my VM that needs to connect to the customer's databases and not the other way around. Site to site is managed on Azure, which I cannot really test locally.
Conceptually, connecting to the customer's network via a point-to-site VPN seems more suitable (by creating the VPN connection in Windows itself via the network config).
The customer prefers site-to-site even though they don't need to connect to my VM. Am I missing something?
In point-to-site, you have to connect to the network you want to access manually. Usually, if you log-off or restart the workstation it loses connection, and you have to reconnect every time. It's common to use this type of VPN when we are working remotely, and we need to access our company assets. The channel is bi-directional, but it's 1-to-many.
Site-to-site is used when you want to connect two networks and keep the communication up all the time. It's also bi-directional, but it's many-to-many and stays up no matter if your server/workstation is running or not because the connection is established through a network gateway and not from the computer operating system.
In Azure, the Virtual Network Gateway is the platform providing both functionalities. You can configure site-to-site to connect to your customer network. If this network is not running in Azure, they usually have an appliance to establish dedicated tunnels. As long as it supports IPsec IKE, you are good to go.
If you are using the VM in Azure as a workstation, then point-to-site may be enough, but if your application needs to get data from the customer database automatically with or without someone logged in the VM, then site-to-site is a better approach.
A better explanation can be found here

Difference between Azure Connect and Azure Virtual Network?

Azure Connect is a service found on the older Azure.com portal and allows connectivity between on-premise and cloud servers/roles/resources. It creates a virtual IP (overlay) network - pretty much a VPN.
Azure Virtual Network (found on the new Azure portal) is ALSO touted as a VPN solution for also the same purpose however the configuration seems a lot twisted (although with a pretty UI).
I'm confused how these two product stack up against each other. Googling and searching MSDN didn't reveal much information either.
What are the differences between them and the target use-cases? Are they expected to be merged into one product down the road?
The use case for us is a WebRole that's running as a cloud service, whose REST/Web API services are consumed by machines on a private network. Azure Connect or Azure Virtual Network would (should?) provide the underlying connectivity between them.
Azure Connect allows users to connect Azure applications with on-premise servers in a super simple and quick way. It does not require VPN devices, it does not require user to have network knowledge, it does not require/assume user have access to network infrastructure (e.g. ability to configure the firewall at company's edge firewall). You express your connectivity intent (e.g. Azure service x should connect to a set of machines (machine group) y on-premise) in the management portal, Azure Connect does the rest for you. It is also very flexible in that you can change the network and connectivity policy at any time via the portal, without requiring redeployment of your app or any change on-premise. e.g. you can make Azure service x to connect to machine group z on-premise instead of y, once you make that change in portal, the rest happens automatically, machines in y are not long accessible to/from Azure. Azure Connect uses endpoint software to manage all the network connectivity for users, so you do have to install endpoint software. But it supports many different automatic deployment options including using Microsoft Update.
Azure Virtual Network allows user to extend part of their on-premise infrastructure to your Azure virtual network via standard site-to-site IPSEC connection. You must have an internet facing VPN device at on-premise side. The solution also assumes you have network knowledge - you will be asked to specify the network address range you will be using at both Azure and on-premise sides, you will must launch a VPN gateway at Azure side and manage the IPSEC connection. It does not require install endpoint software on servers, you are responsible for setting up routes to route the traffic from VPN device to servers and vice versa.
The two technologies complement each other, they are suitable for different scenarios.

USB sync of local database to WP7

I have a requirement where data on SQL server needs to be synced to WP7 devices through USB.
I initially thought of writing a WCF Lib., but it'll go online & sync even if device is connected to USB in local network (Where it's easy & cheaper to get data over local network rather than go to internet & get it).
I have coded isolated storage to save the data synced, but i need an efficient way of getting data from local network, while it's connected to local network.
My questions are:
Is there a way to request data from local network when connected to local network in WCF?
Does someone have a C# code i can use to write synchronization routines to usb over local network? (I would love to have the code, if anyone has this)
Is there a better way of achieving what I'm trying to do?
I'm hoping for some quick answers for this problem, any help is greatly appreciated.
Thanks.
My recommendation would be for your WCF API to have an DNS name pointing to an internal IP address, which is not available outside of the local network and in the routing it will get resolved through USB and another DNS name pointing to an external IP Address which is only available outside of the local network. Your application would try to connect using the local IP address first, which should go through the local network and if it fails it should retry the with external option.
You can use NetworkInterface.NetworkInterfaceType to detect a connection of type Ethernet.
Implementing a full sync protocol is complicated and not something I would recommend attempting unless you really have to.
If you do go down this route I'd recommend using item based message queues and then syncing the queues (and replaying as necessary) rather than trying to sync database tables. It'll depend on the requirements of your application and nature of the data though.
Further to both Murven and Matt's answers, I'd recommend looking into the Microsoft Sync Framework, which supports WP7 as a client, commonly uses WCF on the server, and has great support for a wide range of edge cases.
You can then, as per Matt's answer, watch for connectivity changes and, on USB connection, start a sync to a local IP.
When it comes to targeting mango, you can implement it as a ResourceIntensiveTask and it will run when USB is connected, even if the app isn't running.

Resources