Searches for remote peer.

None  

object.Search Type, RemoteID, [Arg1], [Arg2], [Arg3]

The Search Method syntax has these parts:

The settings for Type are:

Constant		Value	Description
	SrchUDPSingle	0	Search using single UDP packet.
	SrchUDPDouble	1	Search using double UDP packet.

Search method is used when remote peer's IP/Port are not known, and needs to be located. Usually, "middle man" or "the mediator" is needed to locate such peers. Both peers announce themselves (in some way) to the mediator, and he exchanges information about peers with other sides. After that mediator's job is done (he can be closed..) since both peers try to establish direct connection.

There are many ways to search for other peer, and we will add new search types as we see that there is need for them. Since there is no general rule on how mediator works and operates, this can be even your own idea to make mediator on top of other protocol (typical example is Wippien www.wippien.com that uses Jabber protocol for mediator).

Depending on search type, this is how wodVPN behaves and what is needed for Search to succeed. Both peers should use same search type in order to locate each other:

SrchUDPSingle:

This type sends UDP packets each few milliseconds (as defined in RetryWait property). It is expected that other side does the same. RetryCount property defines how long it sends packets - if you set that property to 0, then you can leave your wodVPN searching as long as you like. Each packet contains local ID and remote ID information, along with some data that needs to be transferred to remote peer.

 

Mediator for this search type is very simple. It just waits for UDP packets on some port. When search request arrives, he checks if he has same such packet from requested remote ID. If he finds it, he sends UDP packet back to originator about remote peer's details. That's it. He keeps only last 15 seconds of packets in memory, so as soon as remote peer is located, mediator forgets about him. This way same mediator script can work for unlimited number of peers at the same time. We have such mediator on "mediator.weonlydo.com" on port 8000 for you to use during tests. You can find full mediator script here.

 

As soon as mediator has both peers on his list, and he replies back to originating peer about other side, both wodVPN instances receive those packets and will try to establish direct connection. They do so by connecting to and around received remote peer's IP/Port. If just one packet manages to "pass through" to other peer (and it does so in 99.9% cases) link is established, and SearchDone event is fired. This technique is called "UDP hole punching" or "NAT traversal" and allows peers to connect directly even both are behind NATs or firewalls

 

When you call Search method, you will see that state is changed to "Searching for remote peer address" while wodVPN awaits to receive UDP packet. When packet is received, wodVPN tries to link with remote peer and state changes to "Linking with remote peer". You are not yet connected to it! You are just prepared to do so!

 

After successful search, you can call Connect method with parameters from SearchDone event

 

To correctly use this type of search, you should put hostname of the mediator in Arg1 (such as "mediator.weonlydo.com"), and port of the mediator in Arg2 (such as 8000). Don't forget to specify remote peer ID, such as this:

 

VPN1.Search SrchUDPSingle, "MyFriendBill", "mediator.weonlydo.com", 8000

 

Optionally, you can add inside Arg3 some custom text you want to send to remote peer. Remote peer then can read data that was sent inside Search method using PeerData property.

SrchUDPDouble:

Very similar as SrchUDPSingle, except requires two UDP packets to be received from the mediator. Not to go deep into technical description why so, but second packet is actually used for "hole punching" since it is more recent. First packet that is used by your local NAT to perform address translation may be hours old and could lead to failure when trying to link to remote peer.