netdemo echoServer issue [was: Re: listen/select and then accept pattern not working?]

[Karel Gardas]

On Mon, 17 Jan 2005, Joel Sherrill <joel at OARcorp.com> wrote:

>
>
>
> Karel Gardas wrote:
> > Hello,
> >
> > finally I'm able to run MICO-based CORBA server on RTEMS. The only issue
> > is that the server seems to be somewhat limited in a number of connection
> > it can open/serve. Precisely, it is able to serve/use just one TCPIP
> > connection. My listen/select issue was caused directly by this fact, since
> > before running whole CORBA server logic, MICO tries to find the name of
> > the computer which results in a remote connection going outside (DNS) --
> > at least I see opened socket in my debug printf hacks done to the
> > under-laying RTEMS. Then when server tries to do its thing it was not able
> > since the only one available connection was already consumed. When I force
> > MICO to not do any resolving and so not opening any connection outside
> > before serving its client, I'm finally able to get hello world server on
> > RTEMS running and even serving its client well, but as I said, the number
> > of clients served is exactly one: the first client runs well and the
> > second, third, etc, are not working since they are not able to connect
> > server side. (clients are running on Linux and server on RTEMS)
>
> RTEMS is full of configurable limits.  The first one which comes
> to mind is:
>
> CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
>
> Each socket consumes a file descriptor.  This parameter should
> cover all the implied resources.

Hm, I've tried with 40 but even increasing it to 400 does not help.

> Since this is a connection issue, that would be my first guess.
> I recall Gene Smith having problems with connections that he
> opened/closed fairly quickly.  They didn't get reclaimed fast
> enough for his tastes.

Interesting. I have different issue: the first connection come OK: NIC
(I'm using ne2000) signals received packet, then yet another packet,
socket A (my guess is that this is the socket on which server is listening
by using select) is wakenup, then socket B is wakenup (my guess is that
this is socket created by accept call), again several times socket B, then
Hello World is printed (CORBA servant is invoked), again several times
socket B is wakenup, again NIC receive packet, then several times socket B
is wakenup and that's all. For the second client run, RTEMS even does not
signal received packet on NIC nor it signals wake up for socket A, but
strangelly signals wake-up on socket B several times.
Note: Socket A and socket B are two different socket pointers obtained
during RTEMS debuging.

> I would like to get your RTEMS network configuration for qemu. I haven't
> had a chance to play enough to get this working and am always willing
> to take a handout :)

Unlike Lars, I'm using user-net functionality which does not require any
scripts run as root. My invocation like looks:

sync; qemu -isa -user-net -nics 1 -macaddr 21:03:76:12:09:75 -redir
tcp:8880:10.0.2.7:24742 -fda /tmp/grub-boot.flp -hda /mnt/karel/rtems.img
-boot a -m 32 -redir tcp:8881:10.0.2.7:12345 -redir udp:2071:10.0.2.7:2071
-redir udp:2073:10.0.2.7:2073 -redir tcp:6661:10.0.2.7:80 -monitor stdio

sync before qemu is for safety purposes, since it forces sync on device
mounted as:

/dev/loop0 on /rtems type ext2 (rw)

which is a file /mnt/karel/rtems.img containing ext2 partition holding all
RTEMS testing applications. (note: I have /rtems mounted even when I
start/quick qemu, so basically as a developer I just need to copy my app
to /rtems and start qemu by using line above)

You also can see that I boot from GRUB-based floppy which allows me to
start RTEMS apps from /mnt/karel/rtems.img (i.e. hd0,0 in grub) then. Also
you can see several network redirects for netdemo, rdbg, my CORBA hello
world server and RTEMS's webserver (which is also not working because of
the same issue) and that I'm using 10.0.2.7 as a RTEMS ip address.

Thanks,
Karel
--
Karel Gardas                  kgardas at objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com