@Lingerance said:
@Corvidae said: Long time reader, first-time poster, etc.
This meme should die. We can see your post count.
This was only intended to be a "I think I kind of know how things work around here, even though I just created an account" thing, not as an attempt to look trendy with a (lame) meme.
@Lingerance said:
One thread for a few clients could work. But one thread per socket would be easiest. Doing two threads is WTFy.
One thread per socket I understand. How can I get separate read and write queues with just one thread, though, considering that one direction can't block the other, short of having state flags and spinlocking the thread as it keeps checking to see if I have anything to read/write? That strikes me as a far worse solution.
@Lingerance said:
With select() you don't need to block. As for the question as stated: if you use the native socket API the scheduler is informed correctly of the situation and behaves accordingly.
I'm using C#, but I'll assume for now that it's being converted to raw Win32 socket commands and will work the same way. Thanks for the confirmation (I seem to remember the Win32 scheduler being crap in that regard, but that was a long time ago).
@Lingerance said:
Look at the code for an open source IRC or HTTP server.
The problem with doing that is licensing pollution; unless I went with an old BSD package or something, I could run into legal issues with that. Then again, POSIX is POSIX, so...
@stratos said:
Perhaps this is simply me applying my hammer to every nail I see, but
wouldn't it be a lot easier if you could adapt the client to actually
do the whole "request, respond, disconnect" procedure.
I need to be able to keep sessions persistent for security and some other architectural concerns. If I have the clients disconnect after each request, then the server can't update them with additional information unless we have the clients open ports for the server to connect to, which will cause a bunch of problems with firewalls, NAT, etc. Much simpler to just keep the connection alive, provided we can make it scale sufficiently.
Thanks for the input!