block, end, async read/write cause delay?

[Ryan Liu]

Will TcpClient.GetStream().Read()/ReadByte() block until at least one byte
of data can be read?

In a Client/Server application, what does it mean at the end of stream/no
more data available? Client could send data once few seconds of minutes. Is
there an "end" at all?

In a C/S application, if server side call BeginginRead() again in EndRead()
to create a endless loop to get message from client, is this a better
approach than "one thread per client" approach?

I understand aync read/write will put job into query and later it uses
system thread pool to execute it. The question is when will it be executed?
Wait until hardware available or plus waiting thread available? If there are
too many clients, will this async approach cause too much delay and client
can not get expected response from server in timely manner? And this can
avoid by "one thread per client" mode?

Thanks!
Ryan

 

[Ryan Liu]

Thanks a lot, Peter.

Just one more question :

Assuming the socket is in blocking mode, yes. Otherwise, you could get an
exception equivalent to the WSAEWOULDBLOCK error.

What does Block meaning? Will it consume resouces like CPU? Will it occpuy a
thread? Is it just a hardware thing, e.g. wait for hardware to notify or
actually use thread poll status of stream?