PureBasic Forums - English

Hello,

Is there a clean and cross platform way to wait for network events without using Delay() in loop (with NetworkClientEvent() or NetworkServerEvent()) and without using all cpu ?

I run a linux server coded in pure basic, and if I use a Delay(1) in network loop it will use a bit too much of cpu (server process is #1 in "top"), and if I use, for example, Delay(100) it will works fine for cpu but it's too laggy for clients, server will not answer quickly !

That's a shame we don't have a blocking network lib in PB with a function such as WaitNetworkServerEvent(), that will make a server answers very quickly without stealing any CPU if there is no request from clients...

We are in 2014, PB community is growing, and we still use a very bad Delay() in network loop ? Come on Fred, stop the joke.

There are no delay()s in the examples. Why do you use them?

As far as code goes, i've only seen serial data transfers use delay() because they don't have a 'listening' layer as networking protocols do - it works more like a timing layer in which delay() is useful. In that sense, properly implemented networking protocols do not need the intervention of external code.

I think, you can replace the Delay() with Yield()

Jagermeister wrote:There are no delay()s in the examples. Why do you use them?

As far as code goes, i've only seen serial data transfers use delay() because they don't have a 'listening' layer as networking protocols do - it works more like a timing layer in which delay() is useful. In that sense, properly implemented networking protocols do not need the intervention of external code.

If you don't call Delay() it will use 100% cpu, and that's really bad. Simple as that.

ts-soft wrote:I think, you can replace the Delay() with Yield()

Code: Select all

Procedure Yield()
  CompilerIf #PB_Compiler_OS = #PB_OS_Windows
    SwitchToThread_()
  CompilerElse
    pthread_yield_()
  CompilerEndIf
EndProcedure

Thanks for sharing tip, but that's seems to be a hack, and not really reliable.

Compiled the NetworkServer.pb from the help file and it stays at 13%. Pretty sure listening is part of the TCP stack and thus built into the library. Every network request would collide horribly if it relied on human coordination.

https://learningnetwork.cisco.com/thread/5769

Generally when people design applications in TCP/IP they need to get it down to IP and Port Level do the encoding and have it hand over to TCP that will break it into segments and ensure end to end delivery or UDP that will just break it down and send it.

25% on my Win7 x64.

Having the server app simply idling and consuming 25% is terrible.

Not even Torrent app with all that is going on uses CPU.

Hi,

if you want a waiting network functionallity, you have to switch over to sockets.

http://www.purebasicstreet.com/?p=code_ ... g=en&cat=3

Than you can use accept and something like this to use unblocking mode

Bernd

Thanks for sharing your code. I already coded my own network library, but I was wondering if there is a 100% PB solution, without calling API from OS. Seems not.

I can't understand why Fred does not include an option to make blocking socket in official PB network library. Wtf seriously in 2014 ?
It just take 5 minutes of time to add this option to existing PB network library... :/

Can't you call those functions and examine the value they return? They don't block so that should be doable.

Having never built a server myself, I was wrong. Found some interesting topics though:

http://www.purebasic.fr/english/viewtop ... it=sockets

http://www.purebasic.fr/english/viewtop ... 24#p402824