Re: Nsock unconnected sockets

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/04/2010 10:52 AM, David Fifield wrote:
> On Sun, Oct 03, 2010 at 10:03:41PM -0500, Kris Katterjohn wrote:
> > I can't think of a better separate function name right now either, but an API
> > change of something like
> >
> > nmap.new_socket(<proto>, <family>)
> >
> > with optional arguments is what I first thought of as an alternative because
> > your "setup" is akin to an actual socket() call anyway.
>
> Yes, that's a good interface. It is more magical though. Normally after
> calling new_socket you have only an Nsock iod, not a real socket that
> you can start sending on. The socket doesn't appear until you connect.
> I'm afraid that adding parameters to new_socket will make people think
> that they should do
>
> s = nmap.new_socket("tcp")
> s:connect(host, port, "tcp")
>
> when that would be wrong and would actually have created a socket twice.
>
> > However, I'm not sure if setup() can be called multiple times or not, or if
> > new sockets should be created (in fact, I'm not sure about connect either).
>
> I think that connect and setup both leak a socket if you call them twice
> without closing. But that can be fixed.

Well, given that scripts shouldn't be connecting multiple times (which leads
me to believe there should be one connect() for each new_socket()), then a
possibility is this:

s = nmap.new_socket(<protocol>, <optional family>)
s:connect(host, port) -- remove/deprecate protocol arg

As I was mentioning, scripts (I suppose) aren't changing between TCP and UDP
connect()s on the same socket without closing (or at all).  So specifying the
protocol in new_socket() for the life of the socket shouldn't be a problem for
current scripts.

A socket just created with new_socket() is (I think) essentially useless until
you connect it or "setup" it, so I'm not sure we're losing much in that.
Scripts should know what protocol they want to use by the time they call
new_socket() anyway.  For example, scripts shouldn't call new_socket() and
immediately pass it to some function for connecting when the function can
create it itself (I'm trying to think of any reason why new_socket() calls and
connect() calls may legitimately not be in sync).

Possible downsides I see right now:

* API shift (see below)
* Maybe scripts have some real reason I can't think of to change protocols on
a socket instead of just creating a new one.  Feel free to correct me if I'm
missing something obvious, but these scripts would possibly be leaking a
socket in the current NSE anyway.

Adding the unconnected functionality is a change from how things have always
been done in NSE scripts, so maybe changing the API this way isn't so bad when
new_socket() doesn't do much and you'd be adding a new separate function anyway.

Hopefully there are no glaring holes I'm blind to, but I just got back from a
long day so please bear with me :)

> > Using "udp" sounds good, but my resolve() and address_family() functions use
> > "inet" and "inet6", which I like best (I considered "ipv4" and "ipv6" for
> > them, too).  I don't like the nmap.AF_INET constants either, but using "inet"
> > in there just seems better to me.
>
> Thanks, that's just what I was looking for. I didn't know that there was
> already a convention.

Cool, sounds good.

> David Fifield

Cheers,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMqoqiAAoJEEQxgFs5kUfuns8QAMbIkW5Ym4aqV6+EZUD6uFr4
xPEELwB2OYq1jTvTUwIW6d3nuBHxkGio913z44mWrSkg6YUta7/u3iI/C2NYSMLW
OlWtqYJwu5oE/+j7I8oLczgwmhrCiDb/BrEOXZUSOYeQhn2k0Fl+g12u5RaJbpL0
3nVxQB2SHnlM7jlfFUvgAkj92SYqNixDDcUj09qFr+rX/wxaHJUMsJroZFZEIYK3
igT2BU0q+dwJEjN2k9IvJZLok8IeB7gbsY5gOtEUm4uXXdPQAwyWaESZW4voe5U3
MLGwDRl5FnZmCWmPemlj+M0kwevhKRtEnuZd2nGojB8t8NHVZwBA6Rrm13nCJaFP
LyTXCyVU9Ca0vrNlLEEQrt5yvvGMfkctmI5Ezmr6hKvB7pnc/w95RvSp6jovcIFM
UHLcQP1ashEE1ummfsCVimk6+yshHSWwmDWrMqtLqigPtOvfSWlX9fGT1IUTB6KY
1VVHost011Q+K94tFy/7+wSfuC89L8xlwdPe1QHssUmG4JIMs2AukzbHx6xPi/Ml
svnIro1gk3/XhmlFEKiFrDsuenHvKagKwrDOOKS7mM2gRIKEYrX94UZDuXE6ATCE
xFGF4XnCHIF6qAbC2n5tTF/tvuUj9/uo9n1J2BIlt92wQf8Tv5egNPTcyuaTdZ/q
rMFIrebfEfOjNt8N7aNR
=Y7oH
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/