Prev: Updating the value of Sales Header automatically in Sales Line
Next: Signed External CLR produces Bad Version of Provider Error
From: milop on 16 Mar 2010 06:51
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


From: Peter Duniho on 16 Mar 2010 09:42
milop wrote:
> 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? [...]

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
From: milop on 16 Mar 2010 12:00
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" <no.peted.spam(a)no.nwlink.spam.com> wrote in message
news:eSg%2375QxKHA.5940(a)TK2MSFTNGP02.phx.gbl...
> milop wrote:
>> 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? [...]
>
> 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


From: Peter Duniho on 16 Mar 2010 12:58
milop wrote:
> 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).

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
From: milop on 16 Mar 2010 13:45
It's a beautiful thing.

Thanks again,

Mike

"Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> wrote in message
news:e7dZ4nSxKHA.5940(a)TK2MSFTNGP02.phx.gbl...
> milop wrote:
>> 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).
>
> 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


 | 
Pages: 1
Prev: Updating the value of Sales Header automatically in Sales Line
Next: Signed External CLR produces Bad Version of Provider Error