Summary

Users who pay attention to our GitHub repos might have noticed a new addition in the last few weeks—our networking simulator, sim1h. If you’ve been wondering what sim1h is and how it might affect you, this Dev Pulse is intended to help you understand how to use it and why it matters. We believe sim1h is an important tool for testing hApps, and hope you’ll quickly see more useful tests and reductions in testing times.

We know the word had started to spread that we’re developing a networking simulation tool called sim1h (see our Leadership & Org Update 14). Because of this, we wanted to provide an introduction to this new tool for our dev community. We’re really excited about what it can do in terms of quickly gathering valuable information during testing, and we want to make sure hApp developers can hit the ground running with it. With that in mind, let’s discuss what sim1h is, why it’s an important update, and how to integrate it into your existing testing framework.

Topics

  1. sim1h and its importance
  2. Getting started with sim1h
  3. Next up

Details

sim1h and its importance

In essence, sim1h is a tool for simulating an entire P2P network on a single centralized device. It gives developers a bird’s-eye view of everything that is transmitted through the network. By choosing sim1h in your conductor config, you can start running and testing your hApps right now with an end-to-end user experience of many network nodes. We are doing this internally for our own hApps.

Sim1h is an important addition to our testing tools because it finally lets you deploy a real test network and view all network activity from one machine. In the meantime, we will continue working on our ultimate solution, lib3h, in parallel as we plug in components that we’ve tested and debugged using sim1h.

Debugging

Due to the decentralized nature of Holochain, staging networks, debugging, and analyzing activity presents unique challenge. The biggest challenge is that there is no single source of information about the whole network that developers can access to determine what is working well and what is problematic. Even if we entered Open Alpha Testnet with the whole Holochain stack bug-free (we do expect some bugs—that’s why it’s called an alpha), there would still be many hApps, both internal and external, in need of debugging.

Initially, we were planning to have Holochain nodes and HoloPorts send logs and other state information to a central node for diagnostics. Fortunately, sim1h accomplishes this goal while reducing workload. This is due to the fact that it is running as a simulated network in which we can see all the information nodes exchanging, without having to implement special debugging and analytics code. Distributed applications don’t usually let anyone see all the information being exchanged on the network, but it is invaluable for our short-term debugging needs.

Parallel Development

Sim1h also makes it possible to do parallel staging of our network components, enabling us to move beyond the tandem staging framework we’ve been using thus far. By testing and debugging in sim1h we’re gaining confidence that the individual components of our technology stack are working as expected. Holochain Core works well within the boundaries of its tests and in-memory network, as does lib3h within its test suites that try to mock real-world usage. When we put the two together, however, it leads to a lot of complex behaviors that take time to analyze and test.

Sim1h brings Holochain Core and networking into a fully working Holochain stack so that hApp developers can start testing and using their hApps in the real world. This solves a lot of problems at once. In the meantime, we can now take and replace pieces of the whole system in small iterations. This provides huge improvements for us in terms of time-to-delivery and testing capabilities.

Getting started with sim1h

We encourage you to check out the GitHub page for sim1h to learn more about how to use it in your dev environment. As we’ve mentioned, we’re already using it to test multi-peer activity in our internal hApps.

As of Holochain Release v0.0.31-alpha1, sim1h is built in. To implement, simply select it as the network type in the conductor config:

[network]
type = "sim1h"
dynamo_url = "http://localhost:8000"

If the URL points to a DynamoDB instance, it can be a central DynamoDB managed by AWS (not fully supported yet), your own instance on your local machine, or a test server (accessed by LAN or VPN). In your nix-shell, use the commands dynamodb and dynamodb-memory to start a local instance.

In addition, you’ll need to set two environmental variables when starting the Holochain conductor: AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. These are accessed by Rusoto, the AWS client library we’re using in sim1h to connect to Dynamo. If these are not set, Rusoto will halt before making a connection, which will be visible in the conductor logs.

Please note: If you run a local DynamoDB instance outside of AWS, you will need to keep it on a LAN or VPN to set it up. It isn’t connected to AWS credentials and won’t allow any access key to connect to the database. The variables have to be set, however, because Rusoto requires them. The secret key can be arbitrary, but the access key ID should be chosen carefully as different keys will create different spaces. This can be useful since you can have, for example, various IDs for different teams testing the same app in isolation.

Next up

Sim1h represents a big leap forward in terms of network testing, both of the Holochain stack and all connected hApps. After experiencing this progress first hand over the last few weeks we almost immediately began work on the next step which will be even simpler, faster, and closer to the fully peer-to-peer solution in lib3h. The near-term solutions we’ve chosen at the moment—AWS and DynamoDB—both have their own issues when it comes to interacting with Holochain components. For example, each DNA currently has a table in AWS with the DNA’s hash as table name. Because in AWS you have to create tables manually and configure access permissions by table, managing access permissions can be time consuming.

Moreover, we’re striving to not rely on databases hosted on AWS, even in test environments. Our goal is to have a centralized node for testing, predominantly based on preexisting Holochain and lib3h code. In the meantime, we think that sim1h will eliminate a lot of the difficulties developers have had while testing their hApps. We hope you agree and would love to hear from you either way.

Holochain Forum

Join “Conversations That Matter” on the Holochain Forum to discuss sim1h and share your project’s progress!

Development Status:

Install Holochain Learn about Holochain Join the Discussion