Geoff,
This is a sample of the code I use for the .NET listener
Private Sub MIBS_DoListen()
' Buffer for reading data
Dim bytes(8192) As [Byte]
Dim data As [String] = Nothing
Try
' Listen for new connections.
MIBSlistener = New TcpListener(Sys tem.Net.IPAddre ss.Any,
MIBS_IPORT_NUM)
MIBSlistener.St art()
Do
If MIBSexethread.I sAlive = False Then
MIBSlistener.St op()
End If
' Create a new user connection using TcpClient
Dim client As TcpClient = MIBSlistener.Ac ceptTcpClient()
Dim stream As NetworkStream = client.GetStrea m()
Dim i As Int32
' Loop to receive all the data sent by the client.
i = stream.Read(byt es, 0, bytes.Length)
While (i <> 0)
' Translate data bytes to a ASCII string.
data = System.Text.Enc oding.ASCII.Get String(bytes, 0, i)
Console.WriteLi ne([String].Format("Receiv ed: {0}",
data))
' Process the data sent by the client.
MIBS_endok = 2
Update_MIBS_Sta tus(data)
i = stream.Read(byt es, 0, bytes.Length)
End While
Loop Until False
Catch
End Try
Update_MIBS_Sta tus("DROPPED")
End Sub
I set the port number (MIBS_IPORT_NUM ) at runtime based on a search of
available ports, then pass the port number as a command line argument to the
external PERL app to use as the Client Port Number. This way I never have
port conflicts and I don't need to worry about hard coding a port number
that a certain user may have blocked in a firewall.
For the client, I don't have VB6 code (LOL, actually, I don't have .NET code
either, at least not handy!), but, as long as the port number is the same
(while using System.Net.IPAd dress.Any), the listener will receive whatever
any app dumps onto the port.
While debugging, I write all of the received data to the console as well as
to wherever I want it to go (sometimes it doesn't go where I want it to
go!). So having the console output at least lets me know it was received.
the Update_MIBS_Sta tus function is just a bunch of RegEx expressions that
determine where the data received will be displayed on the form.
I know, somewhere, I have a .NET TCPListener / TCPClient app. If I can find
it, I'll post it for you.
HTH
Lee
"Geoff" <Ge***@discussi ons.microsoft.c om> wrote in message
news:26******** *************** ***********@mic rosoft.com...
Lee,
Thanks! Good to know it should work. That give sme hope.
But I don't seem to be able to MAKE it work. I'm using "locoalhost " as the
server address, and 9001 as the port address.
Do you know of any websites with sample code for communicating between a
"legacy" app and a dotNet app using this technique?
Geoff
"lgbjr" wrote:
Geoff,
There shouldn't be an issue with a VB6 TCPclient sending data to a .NET
TCPListener. Any TCPClient can send data to any TCPlistener (assuming
port
settings and protocols have been setup correctly). I use a TCPListener in
one of my VB.NET apps to collect information sent via a socket by a group
of
PERL apps.
HTH
Lee
"Geoff" <Ge***@discussi ons.microsoft.c om> wrote in message
news:D1******** *************** ***********@mic rosoft.com... >I need to keep a few VB6 tcpClients active, but have them talk to a
>dotNet
> tcpServer/tcpListener. The "Server"/Listener is running as a Plugin,
> and
> needs to respond to "outside requests". The dotNet versions of the
> exe's
> that make these requests take MUCH longer to load and start than the
> VB6
> versions, so I'd like to keep the VB6 versions active (at least until
> the
> dotNet versions will load more quickly).
>
> Is there a way for these legacy VB6 programs to communicate with the
> dotNet
> plugin?
>
> TIA,
> Geoff
