Hi Folks
I've been trying to get a distributed application working over a network. Most of the inter-process communications are handled by a low level server using the TCP/IP stack. For remote processes, communications use port 5005. Not being particularly clued up on low level networking, how do I enable this port ? Just throw an extra problem in, is there likely to be any problems communicating with a Windows box on this port ?
Regards, Paul.
On Mon, Mar 18, 2002 at 07:54:07PM +0000, Paul wrote:
Hi Folks
I've been trying to get a distributed application working over a network. Most of the inter-process communications are handled by a low level server using the TCP/IP stack. For remote processes, communications use port 5005. Not being particularly clued up on low level networking, how do I enable this port ?
Assuming the port isn't firewalled, then you shouldn't need to do anything - just run the application.
To check if the application is listening on port 5000, you can go to another machine on your net and type
telnet host_address 5000 [where host_address is the name of the server]
If it connects, then the app is listening and you are through.
If you get "connection refused", then you probably don't have a firewall problem but the app might not be listening.
If you just get silence, then the port might be firewalled.
Just throw an extra problem in, is there likely to be any problems communicating with a Windows box on this port ?
Probably. But no worse than doing anything else related to windows.
on Mon, Mar 18, 2002 at 07:54:07PM +0000, Paul wrote:
I've been trying to get a distributed application working over a network. Most of the inter-process communications are handled by a low level server using the TCP/IP stack. For remote processes, communications use port 5005. Not being particularly clued up on low level networking, how do I enable this port ?
You shouldn't need to. The "server" software calls bind(2) (try man 2 bind, for the gritty details) and then calls listen(2) and then the process goes to sleep, or does something else whilst it waits. When the TCP/IP stack receives a packet addressed to this port, the operating system sees that the software is listening on the port and address, specified by bind(2), and so wakes that process up, indicating there is a new connection for it to take care of. (I'm assuming it's using TCP, if it uses UDP, the process is similar but different.)
If you are running some kind of firewall, you may want to check the filtering.
If you get error messages like "Address already in use", netstat or fuser can probably locate the offending process.
Just throw an extra problem in, is there likely to be any problems communicating with a Windows box on this port ?
AFAIK, no. The port isn't IANA registered and so is unlikely to have any other service listening on it. A client might be using it, if so, just kill whatever is using that port (netstat is your friend.)
Thanks for the help so far guys.... After checking that telnet B6 5005 would connect, I started to edit some of the NML configs. I just have one error that has me stumped.
[root@Talia emc]# plat/nonrealtime/bin/emcsvr tcpmem.cc 649: connect error: 111 -- Connection refused tcpmem.cc 652: TCPMEM: Error trying to connect to TCP port 5005 of host 192.168.0.2(192.168.0.2). sin_family=2 cms_cfg.cc 1234: cms_config: Error -10( CMS_NO_SERVER_ERROR: The server has not been started or could not be contacted.) occured during TPCMEM create.
********************************************************** * BufferName = emcError * BufferType = 0 * ProcessName = emcsvr * Configuration File = emc.nml * CMS Status = -10 ( CMS_NO_SERVER_ERROR: The server has not been started or could not be contacted.) * Recent errors repeated: TCPMEM: Error trying to connect to TCP port 5005 of host 192.168.0.2(192.168.0.2). sin_family=2
cms_config: Error -10( CMS_NO_SERVER_ERROR: The server has not been started or could not be contac
connect error: 111 -- Connection refused
* BufferLine: B emcError SHMEM 192.168.0.2 8192 0 0 3 16 1003 TCP=5005 xdr queue * ProcessLine: P emcsvr emcError REMOTE B6 R 1 1.0 0 2 * error_type = 5 (NML_INTERNAL_CMS_ERROR) ************************************************************
[root@Talia emc]#
I'm right out of ideas - All the other buffers appear to be connecting except this one.
Regards, Paul.
On Monday 18 March 2002 21:24, xs@kittenz.org wrote:
You shouldn't need to. The "server" software calls bind(2) (try man 2 bind, for the gritty details) and then calls listen(2) and then the process goes to sleep, or does something else whilst it waits. When the TCP/IP stack receives a packet addressed to this port, the operating system sees that the software is listening on the port and address, specified by bind(2), and so wakes that process up, indicating there is a new connection for it to take care of. (I'm assuming it's using TCP, if it uses UDP, the process is similar but different.)
If you are running some kind of firewall, you may want to check the filtering.
If you get error messages like "Address already in use", netstat or fuser can probably locate the offending process.
on Tue, Mar 19, 2002 at 08:46:14PM +0000, Paul wrote:
[root@Talia emc]# plat/nonrealtime/bin/emcsvr tcpmem.cc 649: connect error: 111 -- Connection refused tcpmem.cc 652: TCPMEM: Error trying to connect to TCP port 5005 of host 192.168.0.2(192.168.0.2). sin_family=2 cms_cfg.cc 1234: cms_config: Error -10( CMS_NO_SERVER_ERROR: The server has not been started or could not be contacted.) occured during TPCMEM create.
[...]
I'm right out of ideas - All the other buffers appear to be connecting except this one.
Is there any kind of connection limit enforced by the server running on port 5005? E.g. only 10 concurrent connections, or maybe 60 connects a second. Some inetd's have this by default.
If you run: telnet 192.168.0.2 5005; plat/nonrealtime/bin/emcsvr; telnet 192.168.0.2 5005 If both telnets succeed then something odd is going wrong with emcsrv at an above TCP/IP level, most likely. I noticed the mention of 'xdr' in some of the output. Is it using sunrpc? If so, it might be failing to connect to portmap. /etc/hosts.{allow,deny} can affect this. (The 111 in the connect error might mean port 111 (sunrpc) refuses the connection, but error 111 also happens to be connection refused.)
The emcsvr (along with the rest of the package) has been written to run on a number of platforms - From an ix86 through to Alpha and probably Sun.
With a few pointers from the developers list, along with the debugging pointers here, I now have two linux boxes working together. Tomorrow, I start testing the MS interface ;-( The problem was eventually tracked down to just one config file entry on the client computer. None the less, the help received here has been invaluable in interpreting the error messages.
Regards, Paul.
On Tuesday 19 March 2002 23:35, xs@kittenz.org wrote:
If you run: telnet 192.168.0.2 5005; plat/nonrealtime/bin/emcsvr; telnet 192.168.0.2 5005 If both telnets succeed then something odd is going wrong with emcsrv at an above TCP/IP level, most likely. I noticed the mention of 'xdr' in some of the output. Is it using sunrpc? If so, it might be failing to connect to portmap. /etc/hosts.{allow,deny} can affect this. (The 111 in the connect error might mean port 111 (sunrpc) refuses the connection, but error 111 also happens to be connection refused.)
-
Chris Allen -
Paul -
xs＠kittenz.org