views:

362

answers:

3

I'm curious why is it more pervasive. Does it has a better API?

I remember long ago when i first learned about NAT (i used it for sharing a dialup 14.4kbps modem), i thought that someday every home would have a router with NAT included, but it would "obviously" need also a SOCKS process to be able to open listening ports. When broadband started appearing, it was nice to see NAT as a common feature, and I supposed that SOCKS would be an extra, and slowly become more and more common... but nothing! i had to manually forward ports. then appeared that uPNP, but very few 'serious' applications support it, mostly P2P sharing, games, and some IM.

I still haven't seen any home router to include SOCKS (apart from Linux-based firmware upgrades, of course). does anybody know why??

edit:

as Vartec noted, UPnP is a zeroconf and service discovery, not proxy service. now i know that what i'm referring to is IGD protocol, the NAT traversal service present in home routers, and discovered via UPnP. so, my question would more properly be "Why IGD/UPnP instead of SOCKS?"

A: 

As far as I know, UPnP is zeroconf discovery type of protocol for devices in local networks, while SOCKS is tunnel-proxy server. They are completely different, actually I don't see anything, that they would have in common.

vartec
A: 

these are two different things, socks is a protocol that allows you to route tcp and udp (socks v5) through a proxy server and it's for outgoing connections, routers dont have anything to do with this (except they are acting as a proxy too)

the IGD of upnp is an 'api' that allows you to tell your router that you want to open a port and foward it to a computer, this is for incoming connections.. my linksys came with upnp enabled by default and one app i know to use this is msn messenger (maybe only for file transfers)

Pablote
socks also lets you open a listening port on the proxy and have it forwarded to your app.
Javier
+1  A: 

SOCKS has limitations compared to UPnP. Generally SOCKS requires configuration on each client and isn't transparent to applications (system-wide socket SOCKSification isn't installed/enabled by default on Windows), while NAT even without UPnP mostly works transparently and without any additional client configuration for outgoing TCP sockets and outgoing UDP.

NAT with UPnP also supports server TCP sockets better than SOCKS: SOCKS can only accept a single connection with its BIND request, which is okay for receiving a single TCP connection in a protocol like FTP, but useless for running a server that needs to accept many connections from many clients. SOCKS 4 also had a 2 minute timeout on the BIND request, but a server generally cannot know when the next client will try to connect.

Low-level TCP settings (eg. TCP Nagle, traffic class) also don't work across the SOCKS proxy, but they work through a NAT.

damjan