-
Notifications
You must be signed in to change notification settings - Fork 99
Why Open.NAT
Open.NAT is a Mono.Nat fork created to perform major surgery on it in order to update, refactor, clean and reorganize the old-styled source code, fix defects, add common features and be able to break the backward compatibility.
Here you have the Top 10 reasons that make Open.NAT a good candidate for you projects:
There are projects that are interested only in Upnp devices and don't want to discover PMP NATs. Others, only want to discover and handle PMP NATs instead of UPNP ones. Finally, there are others which wants to discover both. This is possible with Open.NAT.
Applications that add portmappings should remove them when they are no longer required or remove them as part of the shutdown steps. By default, Open.NAT keeps track of the added portmappings in order to release them automatically. Developers don't need to take care of this kind of details in theirs projects. Anyway, a ReleaseAll method is provided just in case a deterministic portmappings release is required.
Developers don't know how long a portmapping can be required in advance and for that reason they tend to create Permanet portmappings (a mapping that never expires). Given that an application can finish unexpectly (because someone unplug the computer, for example) permanent mappings remain opened, that is not okay in most of the cases. Open.NAT allows developers to specify a mapping lifetime and it renew the mapping automatically before the expiration so, if someone unplug the computer, the NAT will release the portmapping after a given time.
If after some time a NAT is not discovered, you can be sure there isn't any NAT available for Open.NAT. This can be because the NAT doesn't support Upnp nor Pmp (or they are not enabled) or because there is simply no NATs. Open.NAT allows to specify a discovery timeout in order to stop the discovery process and let the host application know that no NAT was find.
The discovery process in Mono.Nat is a very time consuming task because it asks all devices in the LAN for all the services they support. It generates a lot of network traffic and then, it has to process all the responses. Open.NAT only asks for those services capable to map ports, improving drastically the discovery process.
Open.NAT works not only for NATs supporting WANIPConnection service type but also WANPPPConnection service type. To do this, it has to deal with some inexpensive ADSL modems that respond with wrong service type and that used to support only WANPPPConnection.
All the operations with Open.NAT are asynchronous because it is the real nature of operations and developers don't need to wait for an operation blocking the thread, they can do a lot of useful staff instead of been waiting. Remember, these are client-server operations.
You! Of course you need it and for that reason Open.NAT has a wiki page with the API reference, Code examples, Troubleshooting, Errors, Warnings and an always improving Home page.
I am working hard to make Open.NAT the best library in its type and to achieve that goal get feedback and give support is on top of the priority list.
If developers find problems and need support, they can enable the code tracing in Verbose (or All) level and get the full detail about what is going on inside, with the requests/responses, warnings, errors, stacktraces, etc. They can also use the Open.Nat.ConsoleTest project to play with Open.NAT and reproduce problems.
If well it is not warrantied, Open.NAT (v1) looks and feels like Mono.Nat except for the async methods and the added properties and features. Version 2.0 is completly different.
Open.NAT uses .NET Framework 4.5 and thanks to that its code is a lot clearer, easy to read, maintain and debug. It also includes several new goodnesses and fixes.
WANIPConnection v.2 incorporates methods very useful in very common scenarios that will increase the Open.NAT performance. Currently I am working on that.
Open.NAT is signed and that means you can put it in the GAC.