--- 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.
Posted on 2003-04-14 17:58:14 by f0dder
yes, probably got a bit offtopic, thanks for splitting :)
Posted on 2003-04-15 10:40:03 by f0dder
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?

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
Posted on 2003-04-15 10:52:29 by 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
Posted on 2003-04-15 10:55:47 by Thomas
Posted on 2003-04-16 06:35:32 by Thomas
A stray thought:
what would happen if you specify a socket handle to TransmitFile, instead of a file handle? :)
Posted on 2003-04-16 07:19:30 by f0dder

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
Posted on 2003-04-17 13:04:38 by 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 :)
Posted on 2003-04-17 13:14:55 by f0dder
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?)
Posted on 2003-04-23 08:14:48 by Homer
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.
Posted on 2003-04-23 08:17:10 by f0dder
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:
Posted on 2003-04-23 08:25:02 by Homer
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).
Posted on 2003-04-23 08:48:35 by f0dder
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...
Posted on 2003-04-23 09:23:51 by Homer
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.
Posted on 2003-04-23 09:35:35 by f0dder