SSL listening sockets.
Being able to specify more than one port
A way to get the remote address and port from a connecting client before accepting the connection.

+1 for #1 and #3 (I could swear #3 existed somehow, I'm surprised it doesn't). -1 for #2. Multi-port listening isn't necessary when you have wildcard socket events:



This also lets you stop listening on certain ports without closing them all, which you can't do if you used one sockname.

There are reasons mIRC ties 1 port to 1 sockname. mIRC only handles 1 low-level TCP socket per sockname. Listening to any port requires an independent socket descriptor, even if everything is routed to the same place in the end. mIRC's socket data structures would need to be redesigned to poll an arbitrary number of sockets for each sockname at mIRC's scripting level-- I don't think Khaled would be willing to do this, since it's a hefty change away from the current design, and it can (read: will) lead to lots of new bugs until it's properly put through the paces. Properties like .bindport would also need to be completely redesigned, or new identifiers would need to be introduced. And since you can already do multi-port listening, there's no functionality gain, just a lot of painful design changes.

Sidenote for #3: mIRC should use the existing .addr and .port (or .saddr and .sport) properties, not create new ones.

Same here, this is needed.

Yea, I didn't think it through about the multiple ports thing. Just got tired of looping through ports to listen for the same type of connection, and thought "well, I'm requesting this, might as well request that too"

the client's address isn't available until the server accepts the connection - that is, if we assume /sockaccept is essentially an interface for a lower level accept() function. check out:

http://en.wikipedia.org/wiki/Berkeley_sockets#accept.28.29

Indeed, then I'm not sure if it could be added.

Agreed with the first.

As jaytea said with the third, it looks like it is impossible or awkward to implement. There is no real need for it to be implemented. You can simply /sockaccept to a temporary name and then /sockrename the socket based on the information available to you (if you are expecting multiple clients)

It seems like maybe the suggestion was a way to reject a connection based on the address without having to accept it first. I could be wrong.

Ah right, I knew I was forgetting something.

Let's stick to #1 then. I think everyone can agree listenable-SSL-sockets are needed.

In essence, yes. I'd like to be able to check the address to make sure it's not a 'malicious connection' but oh well. Atleast we can hope for SSL-Listening sockets

Correct me if I'm wrong but simply accepting a "malicious connection" doesn't pose a risk unless there is something for said connection to exploit on your system.

Provided there isn't a script and/or mIRC bug to be exploited I don't think there is an issue.

Actually, "malicious" can mean denial of service in the context of socket connections. accept()ing a connection takes up far more system resources (and bandwidth) than dropping the connection on listen()-- before a TCP handshake is done. In fact, FreeBSD has a kernel extension for HTTP servers that blindly accept in this fashion.

Sidenote: after further investigation (by Collective), it actually *is* possible using the Winsock API to get the remote ip/port before calling accept() (technically, WSAAccept). There might be a POSIX way to do this too, but it seems to have drawbacks. You can read about them in the WSAAccept MSDN article.

Accepting the connection, even for a split second, indicates to the other party that (1) a computer does exist at this IP address, and (2) something is listening on this particular port. For security reasons, it would be preferable to not reveal either of these facts if it's not necessary.

While I agree that accepting a connection means that there is a computer at that IP address and that it's listening on that port when it connects, there's nothing saying that as soon as it disconnects that the computer may now be offline and/or not listening to that port any longer.

Even if a second connection was made almost immediately, there's no guarantee that it will be the same computer.

The issue isn't about the remote host "knowing" about your network layout, the issue is that it makes it very easy for a target machine to DoS your system, since each accept() takes up one socket descriptor, a limited resources. AFAIK Windows only accepts about ~256 open descriptors at a time? Something really low. It would be pretty easy for someone to abuse that, even if the connections are opened for a few hundred ms.

Of course, mIRC is not meant to have a robust socket implementation, DoS concerns are better left to your OS or router's firewalls.

Agreed. DoS doesn't concern me too much, not because I don't think I should be concerned, but because I have numerous protections in place.

Lo,

I fully support the idea of ssl server sockets.
I had suggested that sometime ago.

Regards