The Problem:
It's a vexing issue for many users whose machines have Private (LAN) IP addresses (ie are behind some kind of NAT device such as a Router, or use 'ICS' to feed a Hub).
You can't accept incoming connections without configuring your NAT device (or Gateway machine).
That means you can't run Servers, and your p2p-based apps are forced to use only outgoing connections, which often equates to limited service.
Of course, the average user is simply not tech-savvy enough to set up port forwarding, and even if they are, they may be working in an environment where the local Administrator(s) are less than helpful.
The Solution:
There is a standard solution to all these problems, assuming that the Universal Plug and Play ports (udp 1900 and tcp 5000) are not firewalled within the LAN... and if they are, asking the Admin to allow UPnP ports inside the LAN doesn't sound as bad or dangerous as asking for specific ports to be forwarded so you can run a Server (say, in a public library).
It is possible to programatically set up Port Forwarding from any LAN machine.
This kind of support can be added to all Server applications such that they may automatically perform remote configuring of Port Forwarding apon the Gateway Machine, or alternatively, a separate application can be written to remotely view/edit/add forwarded ports, allowing any LAN machine to host Server apps :)
Homer, WHY are you telling us what we (may) already know?
This is just a Heads Up to announce that I've translated the NATUPNP header to OA32 format and will be writing a primitive engine as a reusable OA32 Object Module for public use.
I am essentially doing this to add this feature to my IOCP Server/Client Engine (which currently is used by my VOIP demo, and some other projects), but it is such a useful entity that I will keep it separate from that framework. I may end up enshrining it as a LIB or DLL to allow programmers everywhere to use it, but the initial goal will be OBJ.
Although this is COM/RPC stuff, I am designing this module in such a way as to hide all the ugly COM stuff so that the average OA32 user doesn't need to worry about any of that.
Have a nice day - Prug and Pray :)
It's a vexing issue for many users whose machines have Private (LAN) IP addresses (ie are behind some kind of NAT device such as a Router, or use 'ICS' to feed a Hub).
You can't accept incoming connections without configuring your NAT device (or Gateway machine).
That means you can't run Servers, and your p2p-based apps are forced to use only outgoing connections, which often equates to limited service.
Of course, the average user is simply not tech-savvy enough to set up port forwarding, and even if they are, they may be working in an environment where the local Administrator(s) are less than helpful.
The Solution:
There is a standard solution to all these problems, assuming that the Universal Plug and Play ports (udp 1900 and tcp 5000) are not firewalled within the LAN... and if they are, asking the Admin to allow UPnP ports inside the LAN doesn't sound as bad or dangerous as asking for specific ports to be forwarded so you can run a Server (say, in a public library).
It is possible to programatically set up Port Forwarding from any LAN machine.
This kind of support can be added to all Server applications such that they may automatically perform remote configuring of Port Forwarding apon the Gateway Machine, or alternatively, a separate application can be written to remotely view/edit/add forwarded ports, allowing any LAN machine to host Server apps :)
Homer, WHY are you telling us what we (may) already know?
This is just a Heads Up to announce that I've translated the NATUPNP header to OA32 format and will be writing a primitive engine as a reusable OA32 Object Module for public use.
I am essentially doing this to add this feature to my IOCP Server/Client Engine (which currently is used by my VOIP demo, and some other projects), but it is such a useful entity that I will keep it separate from that framework. I may end up enshrining it as a LIB or DLL to allow programmers everywhere to use it, but the initial goal will be OBJ.
Although this is COM/RPC stuff, I am designing this module in such a way as to hide all the ugly COM stuff so that the average OA32 user doesn't need to worry about any of that.
Have a nice day - Prug and Pray :)
You still can't accept incoming connections .
;)
;)
Are you certain?
Try searching for "lan server port forward".
You'll find a lot of people run servers from behind NATs and across firewalls that would otherwise restrict them.
Try searching for "lan server port forward".
You'll find a lot of people run servers from behind NATs and across firewalls that would otherwise restrict them.
I'm not trying to ruin your post or anything but have you any links that show this without touching the router?
For UDP protocol exists http://en.wikipedia.org/wiki/UDP_hole_punching
However this is not useful to expose a server over the internet but still interesting :)
I forgot to tell, you can accept incomming conections with UPnP, at least on my network uTorrent maps the port on the ICS of my router PC and if I check the list of port forwardings I can see the automatically maped port there.
However this is not useful to expose a server over the internet but still interesting :)
I forgot to tell, you can accept incomming conections with UPnP, at least on my network uTorrent maps the port on the ICS of my router PC and if I check the list of port forwardings I can see the automatically maped port there.
Doing that with udp sounds like nat . :D Very interesting.
http://www.codeproject.com/internet/PortForward.asp
This demo (with C source) supports all the features I intend, but is rather ugly codewise.
Anyway, the binary demo provided allows for testing a built-in webserver.
This demo (with C source) supports all the features I intend, but is rather ugly codewise.
Anyway, the binary demo provided allows for testing a built-in webserver.
Hey homer.
I was talking about without having upnp enabled on the router because most routers have it turned off by default anyway.
I was talking about without having upnp enabled on the router because most routers have it turned off by default anyway.
UDP hole-punching is completely different from UPnP, but a useful technique in itself... and UPnP indeed does let you accept incoming connections. It's either b0rked in my router or the more recent µTorrent versions though :/
Yesterday I translated natupnp.h and today I translated UPnP.h
If you want them NOW, just ask - otherwise wait for my first UPnP Demo, which will include them... or wait even longer for the UPnP Engine which will pretty much just wrap the COM stuff so you dont have to worry about mundane stuff like BSTR and VARIANT conversions and other such nonsense... or wait yet longer for my VOIP Demo which will include an update of my IOCP Server/Client Engine that will in turn utilize the UPnP Engine as a core component 8)
I shall list all the interfaces in each of these files here, in case anyone ever searches the board for them.
FileName: UPnP.inc
Interfaces: IUPnPDeviceFinder, IUPnPDeviceFinderCallback, IUPnPServices, IUPnPService, IUPnPServiceCallback, IUPnPDevices, IUPnPDevice, IUPnPDeviceDocumentAccess, IUPnPDescriptionDocument, IUPnPDescriptionDocumentCallback
FileName: natupnp.inc
Interfaces: IUPnPNAT, INATEventManager, INATExternalIPAddressCallback, INATNumberOfEntriesCallback, IDynamicPortMappingCollection, IDynamicPortMapping, IStaticPortMappingCollection, IStaticPortMapping
What can I say - Prug and Pray !! :lol:
If you want them NOW, just ask - otherwise wait for my first UPnP Demo, which will include them... or wait even longer for the UPnP Engine which will pretty much just wrap the COM stuff so you dont have to worry about mundane stuff like BSTR and VARIANT conversions and other such nonsense... or wait yet longer for my VOIP Demo which will include an update of my IOCP Server/Client Engine that will in turn utilize the UPnP Engine as a core component 8)
I shall list all the interfaces in each of these files here, in case anyone ever searches the board for them.
FileName: UPnP.inc
Interfaces: IUPnPDeviceFinder, IUPnPDeviceFinderCallback, IUPnPServices, IUPnPService, IUPnPServiceCallback, IUPnPDevices, IUPnPDevice, IUPnPDeviceDocumentAccess, IUPnPDescriptionDocument, IUPnPDescriptionDocumentCallback
FileName: natupnp.inc
Interfaces: IUPnPNAT, INATEventManager, INATExternalIPAddressCallback, INATNumberOfEntriesCallback, IDynamicPortMappingCollection, IDynamicPortMapping, IStaticPortMappingCollection, IStaticPortMapping
What can I say - Prug and Pray !! :lol:
Homer, are you doing this to be able to do VoIP in a P2P fashion? Note that if you have a server in which clients connect to, then perhaps you should also give a try to the UDP hole-punching since it enables you to do P2P connections even if your NAT device doesn't supports UPnP nor manual port forwardings.
Homer, are you doing this to be able to do VoIP in a P2P fashion?
YES.. decentralized voice is the game, for fun, not profit.
My IOCP Server/Client Engine is a general purpose networking component that can assign protocol-handler objects to each 'Session' (and can do funky stuff like switching protocols mid-session).
Right now as of this moment, the IOCP engine does not support UDP at all.
The VOIP demo uses TCP only.
However..
IOCP , even under TCP (which ensures that packets arrive, and arrive in the order sent), does not guarantee that packets are PROCESSED in the order received, without the User imparting a formal packet ordering scheme within the carrier protocol.. this kinda makes UDP viable.. if we're going to start marking packets with a "packet number" outside of the IP header, then I can't see much advantage to TCP except for the delivery guarantee.
I will think about implementing UDP in the IOCP framework as I go along with the UPnP stuff.