--- continuation of "recv commands receives everything in one call !" ---
Thanks :) I can't wait digging into the I/O completion ports too but it has to wait, might not be the best starting point for beginners :).
True.
As for the "simpler" methods, how would you say the following would rate against eachother in terms of speed/flexibility?
*) blocking, threaded (read note further below)
*) nonblocking, messages
*) nonblocking, events
for the blocking+threaded, I would try to devise some "worker" scheme, so that you have N worker threads that are preallocated, and delegate socket work to them. This way, you don't have to do the constant (and, in case of heavy load, time consuming) work of thread setup/teardown. I guess this might be similar to IO Completion Ports?
I would assume the window messaging approach to be the least flexible and slowest. Wouldn't really bother me, as I dislike that way of programming sockets ^_^
I expect events to be pretty efficient - of course there's a whole lot of ways to use them (my idea would be a GUI thread and a socket thread that does WaitForMultipleObjects, and doesn't spawn work to worker threads. This of course assumes each socket operation completes quickly).
Oh by the way, I like that you're constantly disapproving of polling. You're sorta the socket authorative on the board; nice to see you live up to this responsibility by being sensible :)
Anyway, time for bed.
Thanks :) I can't wait digging into the I/O completion ports too but it has to wait, might not be the best starting point for beginners :).
True.
As for the "simpler" methods, how would you say the following would rate against eachother in terms of speed/flexibility?
*) blocking, threaded (read note further below)
*) nonblocking, messages
*) nonblocking, events
for the blocking+threaded, I would try to devise some "worker" scheme, so that you have N worker threads that are preallocated, and delegate socket work to them. This way, you don't have to do the constant (and, in case of heavy load, time consuming) work of thread setup/teardown. I guess this might be similar to IO Completion Ports?
I would assume the window messaging approach to be the least flexible and slowest. Wouldn't really bother me, as I dislike that way of programming sockets ^_^
I expect events to be pretty efficient - of course there's a whole lot of ways to use them (my idea would be a GUI thread and a socket thread that does WaitForMultipleObjects, and doesn't spawn work to worker threads. This of course assumes each socket operation completes quickly).
Oh by the way, I like that you're constantly disapproving of polling. You're sorta the socket authorative on the board; nice to see you live up to this responsibility by being sensible :)
Anyway, time for bed.
yes, probably got a bit offtopic, thanks for splitting :)
Originally posted by f0dder
True.
As for the "simpler" methods, how would you say the following would rate against eachother in terms of speed/flexibility?
*) blocking, threaded (read note further below)
*) nonblocking, messages
*) nonblocking, events
for the blocking+threaded, I would try to devise some "worker" scheme, so that you have N worker threads that are preallocated, and delegate socket work to them. This way, you don't have to do the constant (and, in case of heavy load, time consuming) work of thread setup/teardown. I guess this might be similar to IO Completion Ports?
True.
As for the "simpler" methods, how would you say the following would rate against eachother in terms of speed/flexibility?
*) blocking, threaded (read note further below)
*) nonblocking, messages
*) nonblocking, events
for the blocking+threaded, I would try to devise some "worker" scheme, so that you have N worker threads that are preallocated, and delegate socket work to them. This way, you don't have to do the constant (and, in case of heavy load, time consuming) work of thread setup/teardown. I guess this might be similar to IO Completion Ports?
Blocking sockets are probably the slowest. If you use pure blocking sockets, you will need a thread per socket (or two if sending and receiving is not done in turns like most protocols do). With high server load, you will quickly run out of resources (threads aren't lightweight resources :) ).
An IO completion port is an advanced, very efficient and scalable way to automatically create a worker thread queue. The threads still block (you can send custom messages if necessary to interrupt the blocking), but they just wait for something to do, not for the operation to complete. That way they will never block (long) if there's enough to do which is very efficient.
I would assume the window messaging approach to be the least flexible and slowest. Wouldn't really bother me, as I dislike that way of programming sockets ^_^
Window messages are quite poor too, but it is more flexible than blocking since you don't loose control because of the blocking. Messages are slow so it isn't much of a strategy for high performance servers. Personally I don't really like using window messages for anything non-GUI related.
I expect events to be pretty efficient - of course there's a whole lot of ways to use them (my idea would be a GUI thread and a socket thread that does WaitForMultipleObjects, and doesn't spawn work to worker threads. This of course assumes each socket operation completes quickly).
Events are pretty efficient, they are a much faster notification method than messages. There are two basic ways to use them: overlapped or not. Non-overlapped will work like WSAAsyncSelect (ie. notifications on network events), overlapped mode will use the event to signal operation completion. Overlapped is probably faster because it doesn't require calling send/recv again if it failed the first time.
Still one thread might not work very well, since you can only wait for 64 objects at a time (windows limitation). So if you need more connections you need more threads. IO completion ports don't need this and can easily support thousands of connections with just two threads (usually 1 or 2 thread per CPU). You do need to take care of the administration since you will loose the thread-connection relation that way.
Oh by the way, I like that you're constantly disapproving of polling. You're sorta the socket authorative on the board; nice to see you live up to this responsibility by being sensible :)
Hehe :), I can't think of a situation to justify polling in a multi-tasking environment, last time I used polling was on a microcontroller ;).
Thomas
Almost forgot this:
Here's a very interesting article (sample chapter of a book actually) about winsock performance:
http://www.microsoft.com/mspress/books/sampchap/5726a.asp
There's also another article about multithreading performance in general, might be interesting too (haven't read it fully yet):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_threadli.asp
Thomas
Here's a very interesting article (sample chapter of a book actually) about winsock performance:
http://www.microsoft.com/mspress/books/sampchap/5726a.asp
There's also another article about multithreading performance in general, might be interesting too (haven't read it fully yet):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_threadli.asp
Thomas
Some other related articles:
Windows Sockets 2.0: Write Scalable Winsock Apps Using Completion Ports
INFO: Design Issues When Using IOCP in a Winsock Server
Thomas
Windows Sockets 2.0: Write Scalable Winsock Apps Using Completion Ports
INFO: Design Issues When Using IOCP in a Winsock Server
Thomas
A stray thought:
what would happen if you specify a socket handle to TransmitFile, instead of a file handle? :)
what would happen if you specify a socket handle to TransmitFile, instead of a file handle? :)
A stray thought:
what would happen if you specify a socket handle to TransmitFile, instead of a file handle? :)
Hehe :grin: I should test that some time.
Or what about using TransmitFile specifying the same socket for both hSocket and hFile, setting nNumberOfBytesToWrite to 0 (transmit entire file) and a non-empty header buffer ;)?
Thomas
Heh yeah :).
Hm, wonder if it might accept a filehandle in place of the socket? Kernel-mode filecopy - not that it would be too useful :)
Hm, wonder if it might accept a filehandle in place of the socket? Kernel-mode filecopy - not that it would be too useful :)
now I KNOW ur taking the piss - ur well aware that socket handles and file handles are effectively the same thing :rolleyes:
How about this ... SetParent,HWND_DESKTOP,hWnd
"The new parent window and the child window must belong to the same application." is totally untrue, I've parented child controls from app to app without an issue, but I haven't tried parenting the whole desktop to an app ... (is it raining?)
How about this ... SetParent,HWND_DESKTOP,hWnd
"The new parent window and the child window must belong to the same application." is totally untrue, I've parented child controls from app to app without an issue, but I haven't tried parenting the whole desktop to an app ... (is it raining?)
Not 100%, there's a few differences at application level and even more at kernel level. I'm wondering whether the kernel would check for file vs. socket handles... otherwise interesting things could happen.
Well, obviously you can't create a socket handle with CreateFile, but once you have a socket handle, you can use ReadFile, WriteFile and most of the gamut of IO functions to access it (IOCTL etc), as I'm sure u already know...
afaik, most implementations of bsd sockets follow this logic, but I believe originally it was due to sheer laziness in basing the networking io model so heavily on the existing io functionality... I've not tried using Send and Recv to access files, but I'm confident that it would work, since the reverse it true.
Yes, they are like bananas and apples, not the same, but both very fruity :tongue:
afaik, most implementations of bsd sockets follow this logic, but I believe originally it was due to sheer laziness in basing the networking io model so heavily on the existing io functionality... I've not tried using Send and Recv to access files, but I'm confident that it would work, since the reverse it true.
Yes, they are like bananas and apples, not the same, but both very fruity :tongue:
ReadFile/WriteFile/CreateFile etc are pretty damn generic and can be used for a lot of stuff - the same isn't necessarily true for other APIs, just because you can usually use read/writefile to operate on their objects. I doubt recv/send would work on anything but sockets, but - well, I guess it should be tested.
And there's some special restrictions with sockets that don't apply to most other objects - most importantly they are _NOT_ inheritable by child processes, unless the child processes cooperates (look in the winsock reference).
And there's some special restrictions with sockets that don't apply to most other objects - most importantly they are _NOT_ inheritable by child processes, unless the child processes cooperates (look in the winsock reference).
I honestly can't say I've tried that, what kind of access violation does it generate? I've embedded socket code in DLL before, but they are mapped into the process who loads them (or vice versa), so that doesn't count.
In fact I can't even think of many situations where it would be desirable to share a socket across processes !! I do believe you about the inheritance rule, what a quirky, kinky thing to do lol...
In fact I can't even think of many situations where it would be desirable to share a socket across processes !! I do believe you about the inheritance rule, what a quirky, kinky thing to do lol...
It doesn't generate an exception, it just doesn't work - the target app needs to cooperate, and you have to use WSADuplicateSocket. Bit of a shame, since you have to do some rather funky stuff involving pipes (those are inheritable) if you want to pass a socket to a child app.
Can't think of a reason to do it? Think inetd superserver spawning connections off to child apps, with redirected stdin/stdout handles.
Can't think of a reason to do it? Think inetd superserver spawning connections off to child apps, with redirected stdin/stdout handles.