Ivan Milic - Networks expert Ivan Milic CEO Ivan Milic

Top Menu

When you want to start developing an application using quickP2P API you first need to register as a provider. Then you should register your application in the network using one of the provider portals hooked up with the network. All entities of your application regarding quickP2P will be enclosed in application scope. This means that although multiple providers having many applications that can be presented in the network, your application sees only objects that belong to it. Of course what is usually common is that you can have your own super-node(s) hosted on your servers for a single application you have.

So, you start by registering as a provider. After successful registration and login, you get to dashboard screen:  This is dashboard screen of provider portal:

Next thing you need to do is to register your application. Click on "Applications" button below provider contact data.

In the bottom left corner, there is a button "New Application Request". There you enter basic information about your application and submit a request to us so we could enable it. It will appear in applications list but it will not have status active until we enable it.

On a picture above you see example of enabled application. Notice 3 buttons:

  • "View Active Peers"  - enables you to have insight in currently active peers in your application and meta-data
  • "List Virtual Networks" - enables you to have insight in created virtual networks and meta-data
  • "List Virtual users" - enables you to have insight in created virtual users and meta-data
  • "List Virtual objects" -  enables you to have insight in created general purpose virtual object and their meta-data

These 4 options are most useful during development. It is so because programmers can easily see if they are making some mistake.

Let's take a look at peers list: 

 

On the picture you can see 3 records of currently active peers we filtered by query:

"Properties.platform":"windows"  (note quotes for later discussions about queries done from API)

 Besides common networking data, we see in records, most important column would be "Properties". You notice that it has some JSON data format like:

{ "someproperty1" : "some value", "someproperty2" : "some value" }

 What is interesting about that is that we can put any property by our will and later be able to search peers by their value. Our query is exactly that "Properties.platform":"windows" ."platform" property would be custom property someone decided it would need meta-data from its application (although he had OS column given automatically from API).

Let us now look at Virtual User List:

Virtual users and Virtual networks are part of the permanent indexing meta-data storage system. Do not mix that with peers. Record about peer exists as long as a peer is online.  VUser and VNetwork on other hands we can imagine like two database tables on which we can do INSERT/UPDATE/DELETE/SELECT operations.

 We also see "Properties" column. Here we can use in the same way as for peers. The difference is that this data stays saved after peer using VUser object closes session with super-node. You notice first property "Username". Because it is so common that peer-to-peer applications have username/password authentication, we explicitly embedded their use. Same stands for VNetwork "name" property. You can add other properties to your will. In special case if you don't need username/password authentication and you need to use permanent meta-data storage, you can just fix them in some way.

VUser has also two additional fields (looking at VNetwork) "Member Of networks" and "Currently bound Peers".

"Member Of networks" iled that stores list of the unique identification of VNetworks VUser belongs to. The list we see on the picture is from an application that does not use VNetworks at all so all are empty.

 "Currently bound Peers"  shows a list of peers that are currently authenticated with VUser object. Multiple peers can be authenticated using the same VUser object.

We will not talk about Virtual networks and objects lists because they are very similar to VUser list. We mentioned all important things regarding this document section.

Next thing towards starting our application development would be to decide what to use because on some platforms you can choose between .NET and native c++. Here is some listing that may help you decide:

.NET API

Native C++ API

Java wrapper for native c++ API

Windows

Normal .Net DLL

.dll +.lib+headers

Dll + java wrapper sources

Linux

Mono

.so + headers

so + java wrapper sources

Mac OS

Mono

Cocoa .a + headers - you can mix with Obj C++ or use  just c++

IOS

Mono

Cocoa touch .a + headers - you can mix with Obj C++

Android

Mono

(NDK) .so + headers

(SDK)so + java wrapper sources