ASM Community

You really need to do file setup and memory allocation outside your SocketGetfile in case you're responding to a FD_READ event - otherwise you're going to keep overwriting the file data.

Try starting with a simple blocking socket and no events, and try the following code snippet. If that works, we can move on to some proper program structure and event-based handling. Written off top of my head, not tested btw :)

SocketGetFile PROC
	invoke CreateFile, addr lpszDiskFile, GENERIC_WRITE, FILE_SHARE_READ, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL
	.if eax == INVALID_HANDLE_VALUE
		MessageBox, 0, addr szErr1, addr szErr1, MB_OK
		ret
	.endif
	mov		esi, eax

	invoke	GetProcessHeap
	invoke	HeapAlloc, eax, 0, MEMSIZE
	mov		edi, eax

@@doTheFunkyLoop:
	invoke	recv, , edi, MEMSIZE, 0

	.if sdword ptr eax < 0
		; note: memory + file handle leak
		MessageBox, 0, addr szErr2, addr szErr2, MB_OK
		ret
	.endif
	.if eax > 0
		invoke WriteFile, esi, edi, eax, addr fwritten, NULL
		jmp @@doTheFunkyLoop
	.endif

	invoke	GetProcessHeap
	invoke	HeapFree, eax, 0, edi
	invoke	CloseHandle, esi
	ret
SocketGetFile ENDP

Local* and Global* functions are deprecated leftovers from the 16-bit days of Win3.x - new code should be written using the Heap* functions instead. On NT, Local* and Global* point to the same functions, and end up calling Heap* anyway.

GetProcessHeap() returns the current process heap (which is a "pseudo-handle" on all windows versions I know of, but you should still call the function for future compatibility - it's not like it costs a lot of time anyway). This handle is required for the rest of the Heap* functions.

Now, as for event-based async sockets, I'm going for a little explanation and pseudo-code, since writing a proper example takes too much time :)

First off, you will want a per-connection struct with the info you need. This would be State (not connected, connected, error - perhaps more, depending on your needs), probably a BufferPtr, probably a hFile, a Socket, perhaps a Type indicator.

You'll want to allocate an array of these, with MAXIMUM_WAIT_OBJECTS entries. If you want to handle a lot of sockets, make each entry a linked-list or other dynamically growing data structure (and keep track of each pool size, distributing connections evenly across this pool).

Depending on your needs, either reserve slot 0 as a "program shutdown" even, or specify a timeout on your WaitForMultipleObjects() and check a global "shuttingDown" flag.

Create your sockets in async mode, set up Connection structure (with "unconnected" state), allocate buffers, hFile and whatever other state you need, and use WSAEventSelect() to associate the socket with the EVENT for the slot you assign the connection to.

When WaitForMultipleObjects() returns >= WAIT_OBJECT_0, loop through all the sockets for the givent event slot and call WSAEnumNetworkEvents() for each socket, to check whether to process this socket or not.

When calling recv() on a (nonblocking) socket, remember that 0 means "connection closed gracefully", and that you need processing for SOCKET_ERROR - even if WSAEnumNetworkEvents() signalled that the socket has an event. Call WSAGetLastError() and check for WSAEWOULDBLOCK and WSAEALREADY which are non-fatal, and mean you should retry operation next time you get the event.

And umm... that's basically it. Try implementing the above pseudo-code and I'll try finding the time to give you a hand with problems. Remember that memory allocation, file creation etc. happens outside the connection-handler.

Event is an object. If you're refering to the "WaitForMultipleObjects" name, then -for the purpose of your application- I can tell you that it could as well be named "WaitForMultipleEvents". Whole Windows OS is event-driven. Everything just waits for something and acts when particular event occurs. Try to see it this way ^^