Closed richo closed 11 years ago
@richo
I didn't break API compatibility, but if noone objects I'd like to.
Do it if you think it's necessary. I doubt anyone uses the socket extension, let alone Slash yet.
This is pretty good! :+1:
One concern I have is that TCPSocketServer
raises an exception belonging to TCPSocket
. Maybe we should have TCPSocket::Server
or something? Discuss
I did some really shitty throughput testing with it last night:
https://gist.github.com/6749639
and got some totally meaningless results, but at least it doesn't seem to piss memory.
Reusing the error was basically a convenience until I found out what you thought of the idea. My thought is that you should basically do something like:
<%
sock = TCPSocket.new(); // Or TCP6Socket.new()
// then either
sock.bind("0.0.0.0", 7890);
sock.listen(16);
while(conn = sock.accept()) { handle(conn); }
// or
sock.connect("slash-lang.org", 80);
sock.write("GET / HTTP/1.1\r\n\r\n");
Semantically I guess it gets a bit vague if you want to have a different class for each of them, but I'm not convinced that's a realistic need?
At that point, reusing the error becomes less of an issue because there should only be one true Socket class.
I like that. Go for it.
Maybe also add some convenience singleton methods like TCPSocket.client
and TCPSocket.server
.
Sounds good to me. It'll give me a chance to work out how to bundle slash code in an extension.
Ok. Ignore the commit history. I'll rebase before merge.
I've created Socket
which exposes everything common to sockets, and then TCPSocket
as a concrete class wiht a constructor and the remaining stuff that's AF_INET
specific.
I'm about to start on Unix and IP6 support now, and I just realised that getaddrinfo needs hinting on name resolution, but any other comments before I carry on this madness?
Looks great! It'd be rad if you added some tests too.
Pffft tests. (Sure, since there's no setsockopt(2) on Socket right now there's no nonblocking socket operations, so the socket tests will end up mixed up in the Posix tests. Is that a problem?
Otherwise no tests until I implement setsockopt(2)
@richo Yeah, it's not urgent. It can wait until setsockopt is in.
Cool. I just added IP6 support. I'll do unix domain, consider a rebase and then probably call it a night.
@charliesome This looks good to merge to me. Holding off on unix for now.
@richo go for it!
Implements a socket server interface.
I didn't break API compatibility, but if noone objects I'd like to.
Instanciating a
TCPSocket
that connects implicitly is weird. I did some hackery to makeTCPSocketServer#accept
return what amounts to a connectedTCPSocket
but it'd be much nicer if it just looked like the posix API imho.