InterNetwork communication

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am rather new to network programming and need a kickstart. I am looking
for the same idea as the dos prompt or unix, but remote. I want a client app
to be able to send a command to the server and the server respond with an
action. I realize i need to use sockets and TcpListner, but my main
question: how do i keep the connection alive and listening for any commands
until the remote user disconnects? The code i have seen so far just connects
sends then disconnects without staying alive. Thanks in advance!
 
Benny said:
I am rather new to network programming and need a kickstart. I am looking
for the same idea as the dos prompt or unix, but remote. I want a client app
to be able to send a command to the server and the server respond with an
action. I realize i need to use sockets and TcpListner, but my main
question: how do i keep the connection alive and listening for any commands
until the remote user disconnects? The code i have seen so far just connects
sends then disconnects without staying alive. Thanks in advance!

The simple answer is not close the socket at either the client or server
until you need to. Your server probably waits for connection like this:

TcpListener listener = new TcpListener(IPAddress.Any, port);

// Start listening for client requests.
listener.Start();

while(!Stopping)
{
TcpClient client = listener.AcceptTcpClient();
...
...
}

Once you have the TcpClient object from the listener start a separate
thread that will process it. In that thread just keep going round the
loop of reading the data from the stream and writing the response. Only
close the TcpClient object when the listener receives a command like "quit".

The loop might be something like this:

stream = client.GetStream();

Int32 i;

sb = new StringBuilder();
while (!sb.toString().equals("quit")) {
// Loop to receive all the data sent by the client.
while((i = stream.Read(bytes, 0, bytes.Length))!=0)
{
// Translate data bytes to a ASCII string.
data = System.Text.Encoding.ASCII.GetString(bytes, 0, i);
sb.Append(data);
}
stream.Write("recieved");
stream.Flush();
}

Your client app will the work on a similar principal of reading and
writing to the socket until it sends the the "quit" command, at which
point it can close the socket.

Hope this helps.
Jimbo
 
That is exactly what i was looking for! So if there are multiple how do i
handle that?(if you dont mind me asking)
 
Each time you the listener accepts a TcpClient and generates a TcpClient
object you need to start a thread to perform the i/o andprocessing on
that client object. When the "quit" command turns up and closes the
socket then you can terminate the thread.

Does that make sense? I think it does. Are you OK with threading?

Cheers
Jimbo.
 
Absolutly it makes sense (logically). Correct me if im wrong but i would use
a ThreadPool, right?
 
You can do. It kind of depends how long these sessions are going to
last. A ThreadPool is generally used in web server type environment
where there is a simple request/response exchange. That way if there
isn't enough threads available its only a short wait till one becomes
available.

If your sessions are open for a long time then you might be better off
manually keeping track of threads you've started and killed. Then you
can turn away requests with a "server too busy" message if the number of
running threads is too many.
 
Back
Top