Server program not accepting connections

[Daniel]

I have written client and server programs using components
wxTCPClient, wxTCPServer and wxTCPConnection. These two programs are
quite embryonic. At present for some reason the return value of
MakeConnection is false as in the following code from the client
program:

#define TCP_HOST "tux"
#define TCP_SERVICE "TB_SERVICE"
#define TCP_TOPIC "9999"

bool retval = tb_client->MakeConnection(wxT(TCP_HOST),
wxT(TCP_SERVICE), wxT(TCP_TOPIC));
if (!retval)
{
wxMessageBox(wxT("Failed to make connection to server"), wxT("Client
Error"));

tux is the name of the computer that has both client and server
running on it.

In the server program, at this stage I have only implemented OnExecute
for the servers wxTCPConnection object. Is there something special I
need to do on the server before it will accept connections? What
could be going wrong here? Is ther e a way I can see (sniff) the
message sent from the client program? I can post more code if
neccessary.

Thanks.

[Vadim Zeitlin]

On Fri, 20 Nov 2009 16:19:56 -0800 (PST) Daniel <danw...@gmail.com> wrote:

D> In the server program, at this stage I have only implemented OnExecute
D> for the servers wxTCPConnection object. Is there something special I
D> need to do on the server before it will accept connections? What
D> could be going wrong here?

So many things could be going wrong that it's impossible (and useless) to
enumerate them. Why don't you start from the ipc sample, check that it
works (thus eliminating any external problems such as firewalls and what
not) and then simplify it by discarding the parts you don't need?

D> Is ther e a way I can see (sniff) the message sent from the client
D> program?

Obviously any usual network monitoring tools (such as wireshark) work,
there is nothing magic about wxIPC, it's a pretty trivial protocol.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Daniel]

> So many things could be going wrong that it's impossible (and useless) to
> enumerate them. Why don't you start from the ipc sample, check that it
> works (thus eliminating any external problems such as firewalls and what
> not) and then simplify it by discarding the parts you don't need?
>

OK, I'll give it a go.

> Obviously any usual network monitoring tools (such as wireshark) work,
> there is nothing magic about wxIPC, it's a pretty trivial protocol.
>

I tried setting the host name to localhost, interestingly the client
came back much quicker with the
"Failed to make connection to server" message.

[Kenneth Porter]

--On Friday, November 20, 2009 4:19 PM -0800 Daniel <danw...@gmail.com>
wrote:

> Is ther e a way I can see (sniff) the message sent from the client
> program? I can post more code if neccessary.

First verify that the server is listening. Run netstat to list programs
listening on ports. If you see it there, then try to telnet to that port on
that host ("telnet hostname portnumber"). If you can't connect that way, no
higher protocol will work.

[Daniel]

> First verify that the server is listening. Run netstat to list programs

> listening on ports. If you see it there, ...

OK I ran netstat whilst the server program was running (I'm not sure
what I am looking for but)
I did not see any mention of the exe name or "localhost" or "tux".
Should I be looking for a particular I node number?

[Daniel]

Here is my output from netstat:

http://pastebin.com/d32ee08fe

[Kenneth Porter]

--On Saturday, November 21, 2009 8:27 AM -0800 Daniel <danw...@gmail.com>
wrote:

> I did not see any mention of the exe name or "localhost" or "tux".
> Should I be looking for a particular I node number?

Ah, I didn't realize you were running on Linux. That makes it even easier.
Try "lsof -i -n" to list open inet sockets by number. Grep the result
through the port you expect to be listening on or on the name of your
program.

If you use netstat, you need the --listen switch to show listening sockets
that haven't yet received a connection. See "man netstat" for all the
options.

[Daniel]

> Ah, I didn't realize you were running on Linux. That makes it even easier.
> Try "lsof -i -n" to list open inet sockets by number. Grep the result
> through the port you expect to be listening on or on the name of your
> program.
>

I installed and ran lsof and sure enough my server program shows up:

tux tb # lsof -i -n
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tbserver. 4284 root 6u IPv4 10726 0t0 TCP *:41731 (LISTEN)

> If you use netstat, you need the --listen switch to show listening sockets
> that haven't yet received a connection. See "man netstat" for all the
> options.

OK, I tired this also and the program does not show up:

tux tb # netstat --listen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address
State
tcp 0 0 *:41731 *:*
LISTEN
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 5731 /tmp/.X11-
unix/X0
unix 2 [ ACC ] STREAM LISTENING 5827 /tmp/
ksocket-root/kdeinit4__0
unix 2 [ ACC ] STREAM LISTENING 5839 /tmp/
ksocket-root/klauncherMT3901.slave-socket
unix 2 [ ACC ] STREAM LISTENING 5936 /tmp/.ICE-
unix/3910
unix 2 [ ACC ] STREAM LISTENING 5431 /dev/log
unix 2 [ ACC ] STREAM LISTENING 5730 @/tmp/.X11-
unix/X0
unix 2 [ ACC ] STREAM LISTENING 7197 /root/.kde4/
share/apps/nepomuk/socket
unix 2 [ ACC ] STREAM LISTENING 5935 @/tmp/.ICE-
unix/3910
unix 2 [ ACC ] STREAM LISTENING 5807 @/tmp/dbus-
Mqa7NA575E


OK, so what does all this means for my client and server programs?
The server seems to be listening right?

[Daniel]

I solved this, the service string on the client connection must match
the server name
(41731 in the above situation).