Nonblocking read from System.Console

[Tobias Mattsson]

I have a console application that continously serves a set of network
connections, now i want to add a command prompt. So what i need is to poll
for pending input from System.Console in that loop and assemble lines to
interpret. Ive tried using OpenStandardInput to get a Stream object, but
there is no way to find out how much data is pending on such a stream. And
it doesnt support asyncronous operations through BeginRead. So im looking at
using async delegates, but as ive understood it they create a worker thread,
and since i need a call for each character that becomes a lot of overhead. I
could of course just throw console.readline in a thread of its own, but then
i get problems shutting that thread down. I need to get a waithandle from
somewhere and use that in a seperate thread or poll it in the main loop.

In Win32 id use GetStdHandle() to get a HANDLE and then WaitForSingleObject
to poll it, how can i do this in .NET ?

 

[William Stacey [MVP]]

What will you do with the console input? Are they commands to the network
service (i.e. start, stop, etc) or data that the service sends out? I ask
to help formulate a better reply.

 

[Tobias Mattsson]

They're one line commands such as: listplayers, kick <name>, quit, and so
on.

 

[William Stacey [MVP]]

gotcha. Here is what I would probably do. What you really want is a server
and management client. The server will surface a management api as services
like dns, exchange, and others do. That way you mgmt client can be
anything, web client, console client, win client. Your service just runs in
its loop doing its thing. The easiest way is probably surface some Remoting
APIs. Remoting is good for you because your not sharing the management of
the server across the world, but just your management app - so having them
tight would seem good for this.
1) Your server surfaces a few management APIs like DoCommand(command)
2) The DoCommand method will take a string or a command object that you
define.
3) This method will interact with your shared data structors in the server
(need to sync them carefully as normal)
4) So to kick a user (for example) it will lock the users collection and
remove that user and then unlock it. The server thread will lock shared
objects before using them.
5) The method (in this example) could just return a bool that it was
successful or not to your remoting client.
6) You may also have a ListPlayers() remoted method that returns a string[].
7) Your client then just displays the results.

So your server just runs as a service and does its thing in a loop. You can
have one or more management clients that do commands agaist it using
remoting. The client runs as a seperate app in its own process. They can
talk to each other with remoting. Does that help?