Page 1 of 1

command processor question

Posted: Tue Jun 15, 2010 9:13 am
by ellisonsoftware
Hi-

I am looking at the Command Processor Library and trying the telnetcmd example program. I need to accept connections from a couple of different TCP port numbers. In my CmdConnect_func routine how can I find out which TCP port accepted the connection?

I understand that the void * returned from the CmdConnect_func is passed into other CmdXxx_func routines, so subsequent processing will be able to find out which TCP port accepting the connection.

- Mark

Re: command processor question

Posted: Tue Jun 15, 2010 10:13 am
by pbreed
If you only have TCP connections and no serial connections then
If you pass something that is not a tcp fd into the tcp status functions then
they will all return 0;

void * ProcessConnect( FILE *fp )
{
int fd=fp->_file;



IPADDR rmt_ip=GetSocketRemoteAddr( fd);
WORD rmt_port=GetSocketRemotePort( fd);
WORD lcl_port=GetSocketLocalPort( fd);
IPADDR local_ip=GetSocketLocalAddr( fd );

}

If you do include serial ports then take a look at the code in the nburn\examples\telnetcmd example for the process connect
it detects which serial port it is.

If you use the 3rd serial port on MOD5270,MOD5282,MOD5234, or PK70 Blade board serial ports this detection will not work.
As the 3rd through n serial ports are dynamically allocated from the extra FD stash and there is no easy way to know what they are without
recording their value when they are created.

Re: command processor question

Posted: Tue Jun 15, 2010 12:52 pm
by ellisonsoftware
Paul,

Your suggestion works nicely for the TCP connections since the GetSocketLocalPort() provides the port number of the listening socket. I am using the telnetcmd example and have the cases for identifying the serial ports in hand.

Next, I need to block new connections when there is a connection established on a special port. I was hoping a (void *)NULL return from the CmdConnect_func would reject the connection. I believe that if I close fp->_file in the CmdConnect_func, then I will be closing the listener port. So, it appears the alternative is to issue a CmdStopListeningOnTcpPort() for the blocked ports for the duration of the special connection.

Any other ideas appreciated...

I noticed what appears to be a small bug- the "const char *command" parameter passed into the CmdCmd_func will contain the "logout" string from the previous connection if the first command typed in a new connection is simply a [Return].

- Mark

Re: command processor question

Posted: Tue Jun 15, 2010 1:13 pm
by pbreed
Close the listening port,
but make sure to put some kind of timeout on the special port, so if the
special connection dies you can still recover.

Paul