Re: TCP server stop receiving new connections

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Jul 13, 7:22 pm, Julián Rodríguez Bajo
<julian.rodrig...@xxxxxxxxxx> wrote:
Ali escribió:



On Jul 13, 1:46 am, Julián Rodríguez Bajo
<julian.rodrig...@xxxxxxxxxx> wrote:
Alexander Nickolov escribió:

What do you do in your OnAccept handler? In particular,
do you try to accept multiple sockets? A test to try is to
reset the event mask of your listening socket each time you
exit its OnAccept handler.
Also, as a reality check - make sure your message loop
never gets stuck... E.g. when you break into the debugger,
almost always you should end up in the message loop.
Hi Alexander.

In OnAccept I just accept one incomming connection, since as
documentation of WSAAsyncSelect says, FD_ACCEPT is posted after an
accept call if there is another connection request available to accept.
BTW, I have tested with a loop in OnAccept handler to accept all pending
connection requests and behaviour did not change.

The problem is that OnAccept handler is not called for a long time
(maybe 1, 2 or even 5 minutes).

OTOH, the first time I open the server socket, everything works fine,
even if there are 50 clients running trying to connect to the server
before I start the server. But after a shutdown/close/create/listen
sequence the problem appears. Maybe has something to do with the Socket
Notification Window creation/destruction by MFC framework?

Regards.

--snip--
Maybe has something to do with the Socket Notification
Window creation/destruction by MFC framework?

But ofcourse it seems problem with MFC. No offence, but thats the
reason i hate extra libraries, certainly ATL/STL/MFC etc. are meant
for quick development and prototypes rather for every single
solution.

Julián, how about writing a dll that will implement the server using
standard socket interfaces? And from the code portability prospective
you will be free to write number of interface on top of that
_dll_server_. A simple multi thread server would be doing that all and
use windows messaging for moving data back and forth.

Sure, debugging would be far more easy in this layered approach .

ali

Of course you are right Ali, but in the company I work for, rewriting
some parts of the system is not viable. Also, some services that use
this communications library are so huge and so poorly structured and
developed (like one thread adding digits to the end of a string, another
thread removing digits from the begining of the same string, copying the
digit to a global variable and setting a global event for a third thread
to do the real work with the digit) that I am really affraid of this
kind of changes. Since I am almost convinced that the problem is
"inside" MFC and not in my code, I will look for a work around. From my
tests, seems that the first time I create the server, everything goes
fine, so I will check behaviour if I create an extra useless server
right before any real server is created. This way, even after a
shutdown/close of the real server, there will be one server socket (the
useless one), so MFC will not destroy and recreate whatever it does.

Thanks for your suggestions.

Julian, I can understand that you have lot of other gadgets to
integrate in your application not just network interface. But I shall
again suggest to rethink your design If you are going to work for that
company in near future. Yes, separate network interface, use modular
approach and it is the good way to go.

--snip--
Also, some services that use this communications library are >so huge and so poorly structured and developed (like one >thread adding digits to the end of a string, another thread >removing digits from the begining of the same string, copying >the digit to a global variable and setting a global event for a >third thread to do the real work with the digit) that I am really >affraid of this kind of changes.


Hmm, that sounds complicated as it would be, but, I don't understand
how your relating the complexity with network integration? Certainly,
common apps do lot of things beside talking over network. So, the
point is to make it modular and component oriented rather messing-up
all the things altogether.


0)Identify your network requirements of your existing
SuperComplexApplication.
1) Write a standard network interface.
2) Customize your interface that you have developed in step 1
according to your supercomplexapplication.
3) Use step 2 interfaces/functions in your super doper app.


ali

.

Relevant Pages

  • Re: Limiting RMI to localhost
    ... I would like to limit the access to the server only from the interface process and also only from the local machine. ... Is there a way to limit RMI to localhost only? ... A server socket bound to localhost will be able to receive connections from outside. ...
    (comp.lang.java.programmer)
  • Re: Limiting RMI to localhost
    ... and interface) with RMI to communicate between them. ... limit the access to the server only from the interface process and also ... A server socket bound to localhost will be able to receive connections ... server socket factories that used unix domain sockets, ...
    (comp.lang.java.programmer)
  • simple sockets interface using SYSCALL
    ... While a Unix-based Forth system which provides an interface to C ... libraries can easily implement socket i/o for network communications, ... First, star the server, listening on a specified port: ... AF_INET SOCK_STREAM 0 socket to sockfd ...
    (comp.lang.forth)
  • Re: two interface two entry
    ... If you have more then one interface do not use the loppback address 127.0.0.1, use the real server ip address. ... Ethernet adapter Internal Network Interface: ... Connection-specific DNS Suffix. ...
    (microsoft.public.windows.server.dns)
  • Re: What doesnt lend itself to OO?
    ... The whole idea that a subsystem is just ... > The first line exists in the server. ... objects between client and server i.e. as far as the client code is ... > external interface is the traditional input interface whose ...
    (comp.object)