WaitNetworkServerEvent() & WaitNetworkClientEvent()

Poshu · Post by **Poshu** » Sun Mar 12, 2006 1:34 am

Hello Fred.
I would like to see:
WaitNetworkServerEvent([Timeout]) : Wait until an event occurs. It's the same function as NetworkServerEvent() but locks the program execution, which is very important in a multitasking environment.

WaitNetworkClientEvent([Timeout]) : Wait until an event blah blah blah...

The first one is especially important to me.

Thx ^^;

Rescator · Post by **Rescator** » Sun Mar 12, 2006 8:40 am

Hmm, interesting idea but not that nice actualy,
you really should use WaitWindowEvent() or similar instead to control the loop,
and use a Delay(1) in the loop if nothing is happening.

The only advantage I can see of your suggestion is if the program has no interface at all.
But even if it was a service you really do not want it be stuck waiting,
as you would be unable to "stop" the service quickly and more.

Even a simple

Repeat
Delay(1)
Forever

would be better as you would be able to handle various events and situation while checking if network events happen.

Delay(1) hardly uses any system resources at all so don't worry.

You see it is important that a program is not stalled (waiting for something) as the system could decide to kill your program because
it has been stalled (not doing anything), that obviously depends on the way a WaitNetworkServerEvent() where to be implemented though.

This is just my view on this, I'm not too keen on multiple ways to "stall" a app.
WaitWindowEvent() would be usable in 99% of cases.

Hmm, I just checked something and this is a amusing discovery.
WaitWindowEvent() actualy works in a program even if there is no actual window at all.

Code: Select all

Repeat
 event=WaitWindowEvent() 
 Debug event
 Delay(1)
Until event=#PB_Event_CloseWindow

Debug "closing"

Good luck sending a close window message to the windowless program though hehe.

Fred (or anyone else that know), would such a "program" react correctly
to stuff like timer events and system messages etc.?

If so then there would be no need for network waiting as WaitWindowEvent() does the multitasking thing just as nicely

Nik · Post by **Nik** » Sun Mar 12, 2006 12:59 pm

I think the most advantage ould be to have it waiting in Threads as one does normally with the API Recv function

Poshu · Post by **Poshu** » Sun Mar 12, 2006 2:11 pm

I'm working in console mode & don't care about windows, the only way to stop my programme is from the client side.

I can't really use a delay, cause it would slow the my code for nothing (I need speed, so much speed) & no wait would slow down the others threads (cause it's multi threaded).

I can't see any other idea than "waitnetworkserverevent()"
If anyone as an idea, even in asm, I would hear it gladly.

Nik · Post by **Nik** » Sun Mar 12, 2006 2:36 pm

Use Winsock it pretty straight forward and easy to do cross platform since the functions under linux are the same.

Tranquil · Post by **Tranquil** » Mon Mar 13, 2006 11:02 am

Network events could be easily handled as normal window events. Just take a look on the WSAsyncSelect_() command. Its just as easy!

After bindind the socket to a windows message queue its more then easy to wait for a network event.

A delay(1) in a pooling network loop is not the smartest way to handle network events, couse: On traffic usage the delay() slows down your application a lot.

Nik · Post by **Nik** » Mon Mar 13, 2006 2:12 pm

You only do the delay on networkevent()=0 of course, and handling Network events over the window events is definitely slower then the origianl way with a blocking recv in a different thread it's also not nearly as Platform independet. And it's even very good for resources as with a blocking recv in a Thread you do not even need a delay and have the thread waiting in a very effective way.

Tranquil · Post by **Tranquil** » Mon Mar 13, 2006 7:17 pm

Nik wrote:You only do the delay on networkevent()=0 of course, and handling Network events over the window events is definitely slower then the origianl way with a blocking recv in a different thread it's also not nearly as Platform independet. And it's even very good for resources as with a blocking recv in a Thread you do not even need a delay and have the thread waiting in a very effective way.

You are right, I totaly agree! Pooling is faster then message queueing.

Nik · Post by **Nik** » Mon Mar 13, 2006 8:10 pm

And it's what PB currently uses I think (correct me Fred if I am wrong), I thing Fred uses a Thread which waits for recv to finish having the peek flag set, so wehn this event occurs he adds a event to the list of events used bei NetworkEvent()

klaver · Post by **klaver** » Mon Aug 06, 2007 1:49 am

In my opinion it's very needed! Delay(1) is just an absurd - it pauses the thread for ~20ms! It causes a PING 20 ON LOCALHOST...
WaitWindowEvent() is great, why you don't want to add a WaitNetworkEvent() ?

Rescator · Post by **Rescator** » Mon Aug 06, 2007 11:12 pm

klaver wrote:Delay(1) is just an absurd - it pauses the thread for ~20ms! It causes a PING 20 ON LOCALHOST...

Use _timeBeginPeriod(1) and _timeEndPeriod(1) or 2 as value as that improves the granularity of the system task switching and thus Delay(1) can reach around 2ms accuracy.
See the PSDK or MSDN for more info on timeBeginPeriod
Windows Media Player does this I believe, so does the BASS sound libary to improve the system timing on XP and the NT5.x variations. Not sure about Vista but probably the same there too.