ASYNC. Sockets causing message flooding!

Author

122

March 06, 2001 03:42 PM

After reading the tutorial on async. sockets, wrote a simple socket based IRC client in DX... now I got a problem... when receiving a stream of data via my ADSL, I getting a message flood which is slowing down/preventing the user messages (WM_MOUSEMOVE, WM_KEYDOWN, etc.) What is a good solution to this problem? Can I create another window/windowproc to handle just socket messages? Use a seperate thread? Any ideas welcome- thanks, Jason ill-lusion.com
ziggy@ill-lusion.com

laxdigital.com
[email=ziggy@laxdigital.com]ziggy@laxdigital.com[/email]

Shannon Barber

1,684

March 06, 2001 05:07 PM

Heheheheheh

What''s your pump look like? Do you have it sleep every cycle (you should only sleep when there''s no msgs...)?

I don''t think adding a second pump will help here - I think there''s only suppose to be one msg pump per process.

It you''re really getting that bomarded by msg''s I''d switch to a non-msg based method.

- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

Ziggy5000

Author

122

March 07, 2001 10:23 AM

quote:

What's your pump look like? Do you have it sleep every cycle (you should only sleep when there's no msgs...)?

It is pretty standard- think that the speed of the ADSL (30kb+ per sec.) is just too fast for my little (1k) buffer... SO I
raised the buffer and it helped a bit...

quote:

I don't think adding a second pump will help here - I think there's only suppose to be one msg pump per process.

It did help. (I was suprised too...) I just registered another WNDCLASS and made an invisible window to handle only the sockets FD_XXXX msgs. The gui response improved... (never had a frame-rate problem since that's independent in my proggie)..
Each WNDPROC must occur in it's own thread... I should test that...heh

Thanks

ill-lusion.com

ziggy@ill-lusion.com

Edited by - Ziggy5000 on March 7, 2001 11:24:15 AM

laxdigital.com
[email=ziggy@laxdigital.com]ziggy@laxdigital.com[/email]

Shannon Barber

1,684

March 07, 2001 11:47 PM

ahhhh, I see how a second pump helps now (i was thinking dialog boxes, not a second class)

yes a 1k buffer is way too small, 32k might be better, have to trade off space/processor efficencies

What''s the CPU util while it''s receiving?

Magmai Kai Holmlor
- The disgruntled & disillusioned

- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

FordPrefect

122

March 08, 2001 02:59 AM

The size of your input buffer shouldn''t make that much of a difference. Post some of your network code.

Ziggy5000

Author

122

March 08, 2001 07:12 PM

quote:

The size of your input buffer shouldn't make that much of a difference. Post some of your network code.

Here is the code that handles the messages....

    	int w = FindWireBySocket(rb->sRay.lBeamX), b;	switch (WSAGETSELECTEVENT(rb->sRay.lBeamY))	{		case FD_CONNECT:			//MakeWireFlag(w,0);			if (WSAGETSELECTERROR(rb->sRay.lBeamY))			{				if (IsVerbose())					sfprintf ("WIREZ>> Wire %d error on connect (error #%d)!",w,HIWORD(rb->sRay.lBeamY));				Wire[w].dwState = WIRESTATE_CLOSED;				return;			}			if (IsVerbose())				sfprintf ("WIREZ>> Wire %d connected!",w);			Wire[w].dwState = WIRESTATE_CONNECTED;			break;		case FD_WRITE:			if (WSAGETSELECTERROR(rb->sRay.lBeamY)) return;			if (IsVerbose())				sfprintf ("WIREZ>> Wire %d is writable!",w);			Wire[w].dwState = WIRESTATE_WRITABLE;			break;		case FD_READ:			if (WSAGETSELECTERROR(rb->sRay.lBeamY))			{				if (IsVerbose())					sfprintf ("WIREZ>> Wire %d error on read!",w);				return;			}			if (IsVerbose())			{				if (WireMsgFlag[w] == 0)				{					sfprintf ("WIREZ>> Wire %d has incoming data!",w);					WireMsgFlag[w] = 60;				}			} 						b = recv(Socket[w],&Wire[w].lpBuffer[0],Wire[w].dwBufferBytes,0);			Wire[w].lpBuffer[b] = 0;			if (Wire[w].lpHandler)			{				Wire[w].lpHandler->Handle(Wire[w].lpBuffer);			}			while (b != SOCKET_ERROR)			{				b = recv(Socket[w],&Wire[w].lpBuffer[0],Wire[w].dwBufferBytes,0);					if (b != SOCKET_ERROR)				{					Wire[w].lpBuffer[b] = 0;					if (Wire[w].lpHandler)					{						Wire[w].lpHandler->Handle(Wire[w].lpBuffer);					}				}			}			break;		case FD_CLOSE:			if (WSAGETSELECTERROR(rb->sRay.lBeamY)) return;			if (IsVerbose())				sfprintf ("WIREZ>> Wire %d is closed!",w);						break;	}

it get's a little dicey in there- since I use a struct called
a _SFAPI_RAYBEAM to pass message's to object's in my engine (needed more robustness that winmessages would allow). sfprintf()is a function to post status info in the engine, and the each Wire[?] is a struct which keeps info about the socket...

PS. Wire[?].lpHandler points to a class that "handles" the
incoming data as it is received... right now it points to a
console which displays the text as it is received..

whew... hope it's decode-able...
Jason

Edited by - Ziggy5000 on March 8, 2001 8:14:37 PM

laxdigital.com
[email=ziggy@laxdigital.com]ziggy@laxdigital.com[/email]

ASYNC. Sockets causing message flooding!

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

ASYNC. Sockets causing message flooding!

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines