Very helpful info, David. Let me think about this one tonight and I'll respond if anything doesn't make sense. Heck, I'll even try to wade through the C++ code! :-)
Peter -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of David Glauser Sent: Thursday, May 17, 2007 4:41 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] follow-up: Host response It's the way the host was programmed. The socket code accepts a connection, which spawns a new socket that serves as the actual endpoint for the communication. The original socket is still sitting around. The application can start listening for new connections if it desires. A common approach is to start listening with an asynchronous call (BeginListen), passing a callback function to the socket. A connection attempt triggers the callback. Inside it, you call EndListen to get the new socket, then call BeginReceive on it, passing in another callback, which will asynchronously handle data arriving. Meanwhile, as BeginReceive returns immediately, the thread can next call BeginListen again, starting the entire cycle over. If you don't start listening after a connection, then you can't get more than one. The C++ libraries used for the host application probably have code almost exactly the same as the C# libraries - the socket interface is old and well-used. dg -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Peter Osucha Sent: Thursday, May 17, 2007 1:31 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] follow-up: Host response :-) Nefarious purposes, to be sure! Seriously, I have an instrument controlled by a SBC. The SBC has no user interface elements (no monitor, no keyboard, no mouse). The only way to make any modifications to the instrument parameters is by way of an Ethernet connection. I'm trying to figure out how best to rewrite parts of the Host application which isn't doing what it is supposed to be doing. I too think C will 'ignore' the request =- that seems to be the behavior I'm seeing. I just wanted to know if that was the expected behavior due to the way the networking behaved or if that was the way the host was programmed. Peter -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Pardee, Roy Sent: Thursday, May 17, 2007 4:16 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] follow-up: Host response Dude--how many different computers do you need to control your botnet from, anyway? ;-) My guess is machine C will get the finger from machine A if it too tries to connect on the same port. But I'm not confident... -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Peter Osucha Sent: Thursday, May 17, 2007 1:02 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: [ADVANCED-DOTNET] follow-up: Host response A follow-up to the TCP connection questions... Host A which listens for my app on port 6001 has been connected to by a machine B running my app. If machine C also running my app attempts to connect to Host A, what will happen? Peter =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
