Multithread and Sockets

  • Thread starter Thread starter milop
  • Start date Start date
M

milop

Hello.

I wrote an app and am a little concerned about data integrity.

I have a TCPListener listening on a port. When a request comes in I start a
new thread and that thread handles the communication. I'm trying to
understand how/if the communication of each thread is isolated to the
requestor through the same port. That is, since only one port is being used,
how can each thread communicate with the requesting process and not clobber
each other when they are sharing the same port? Does the Stream object keep
things separate?

Thanks in advance - Mike.

Here's a code excerpt:

Public Class Daemon
Implements IDisposable

Private _Listener As TcpListener
Private _ListenThread As Thread
Private _basePort As Int32 = 0
Private _endPort As Int32 = 0

Public Sub New()

Dim port As Int32 =
Convert.ToInt32(ConfigurationManager.AppSettings("DaemonPort"))
Dim iph As IPHostEntry = Dns.GetHostEntry(Dns.GetHostName())
Dim ipa As IPAddress = iph.AddressList(0)

_Listener = New TcpListener(ipa, port)
_ListenThread = New Thread(New ThreadStart(AddressOf Start))
_ListenThread.Name = "Service Daemon"
_ListenThread.Start()

End Sub

Public Sub Start()

_Listener.Start()

Try
While True

If _Listener IsNot Nothing Then
Dim client As TcpClient =
_Listener.AcceptTcpClient()
Dim clientThread As New Thread(New
ParameterizedThreadStart(AddressOf HandleRequest))
clientThread.Start(client)
Else
Exit While
End If

End While

Catch sockEx As SocketException
If sockEx.ErrorCode <> 10004 Then
EventLog.WriteEntry("Socket Error", sockEx.ToString(),
EventLogEntryType.Error)
End If

Catch ex As Exception
EventLog.WriteEntry("Exception", ex.ToString(),
EventLogEntryType.Error)
End Try

End Sub

Private Sub HandleRequest(ByVal ClientObject As Object)

Dim client As TcpClient = DirectCast(ClientObject, TcpClient)
Dim stream As NetworkStream = client.GetStream()
Dim bytes(client.ReceiveBufferSize) As Byte
Dim response As String = String.Empty
Try
Dim i As Int32 = stream.Read(bytes, 0, 1024)
Dim sMessage As String =
System.Text.Encoding.ASCII.GetString(bytes, 0, i)

Dim msg As Byte()

Select Case sMessage.Substring(0, 10).ToUpper().Trim()
Case "GETRANGE"
... do some work, write data back to requestor
Case "CREATE"
... do some work, write data back to requestor
Case "READ"
... do some work, write data back to requestor
Case "UPDATE"
... do some work, write data back to requestor
Case "DELETE"
... do some work, write data back to requestor
End Select

stream.Close()
client.Close()
Erase msg

Catch ex As Exception
If stream IsNot Nothing Then
stream.Close()
End If
If client IsNot Nothing Then
client.Close()
End If
EventLog.WriteEntry("Exception in HandleClient",
ex.ToString(), EventLogEntryType.Error)

End Try
End Sub
 
milop said:
Hello.

I wrote an app and am a little concerned about data integrity.

I have a TCPListener listening on a port. When a request comes in I start a
new thread and that thread handles the communication. I'm trying to
understand how/if the communication of each thread is isolated to the
requestor through the same port. That is, since only one port is being used,
how can each thread communicate with the requesting process and not clobber
each other when they are sharing the same port? Does the Stream object keep
things separate? [...]
Click to expand...

The underlying Socket maintains the identity of the connection. The
local address (IP and port together) is only half the equation. The
remote address is the other half.

So, you may have multiple connections open simultaneously, but each is
uniquely identified by the four relevant pieces of information: local
IP, local port, remote IP, remote port. (Actually, technically the
protocol is also part of the identification…you can have the same local
+ remote address combination for more than one socket as long as each
socket is a different protocol).

Note that all of the above has nothing whatsoever to do with whether you
have more than one thread or not. You can have multiple sockets used in
a single thread, and all the same rules apply.

Pete
 
Hi, Pete. Thanks for responding.

Makes sense. I was able to verify that using NETSTAT.

I guess the call to Socket on the client grabs a port (there's only one
client IP, our mainframe).

Mike

Peter Duniho said:
milop said:
Hello.

I wrote an app and am a little concerned about data integrity.

I have a TCPListener listening on a port. When a request comes in I start
a new thread and that thread handles the communication. I'm trying to
understand how/if the communication of each thread is isolated to the
requestor through the same port. That is, since only one port is being
used, how can each thread communicate with the requesting process and not
clobber each other when they are sharing the same port? Does the Stream
object keep things separate? [...]
Click to expand...

The underlying Socket maintains the identity of the connection. The local
address (IP and port together) is only half the equation. The remote
address is the other half.

So, you may have multiple connections open simultaneously, but each is
uniquely identified by the four relevant pieces of information: local IP,
local port, remote IP, remote port. (Actually, technically the protocol
is also part of the identification…you can have the same local + remote
address combination for more than one socket as long as each socket is a
different protocol).

Note that all of the above has nothing whatsoever to do with whether you
have more than one thread or not. You can have multiple sockets used in a
single thread, and all the same rules apply.

Pete
Click to expand...
 
milop said:
Hi, Pete. Thanks for responding.

Makes sense. I was able to verify that using NETSTAT.

I guess the call to Socket on the client grabs a port (there's only one
client IP, our mainframe).
Click to expand...

Typically, client code will specify 0 as the port number, which causes
the OS to select a port automatically from a range of those available.
Clients can in fact explicitly choose a port, but it almost never makes
sense to do so.

Regardless of how the client selects its port, everything I wrote before
still applies. Your server will never see two different connections
that have the same remote IP address and port number, so the connection
can always be uniquely identified by that combination of four (or five)
attributes.

Pete
 
It's a beautiful thing.

Thanks again,

Mike

Peter Duniho said:
Typically, client code will specify 0 as the port number, which causes the
OS to select a port automatically from a range of those available. Clients
can in fact explicitly choose a port, but it almost never makes sense to
do so.

Regardless of how the client selects its port, everything I wrote before
still applies. Your server will never see two different connections that
have the same remote IP address and port number, so the connection can
always be uniquely identified by that combination of four (or five)
attributes.

Pete
Click to expand...
 
Back
Top