Hello Carsten,
I'm back in my office now. Your patch seems to work for as expected. Thanks.
BTW(1): What is the meaning of the erase operation to the destination string in
the GroupMCastConnection::disconnect() function?
line 156: _destination.erase(_destination.begin()+index);
BTW(2): I was wondering why your patch includes additonal brackes around line
533:
for(m = ack ; m != send && dgram[m]->getId() != response.getId() ;
m = (m+1) % _windowSize);
{
send = m;
}
There's a semicolon closing the for loop in line 531. Just wanted to make sure
the brackets are not intented for that...
BTW(3): How about the network stuff in OpenSG 2. Is it completely new delevoped
or may these changes also need to be applied to the 2.0 code?
Thanks,
Michael
-------- Original-Nachricht --------
> Datum: Wed, 28 Sep 2011 12:47:58 -0500
> Von: Carsten Neumann <[email protected]>
> An: [email protected]
> Betreff: Re: [Opensg-users] OpenSG1.8 - Disconnecting
> ClusterWindow and ClusterServer
> Hello Michael,
>
> On 09/28/2011 06:48 AM, Michael Raab wrote:
> > I'm quite sure that the right socket is removed from the socket list and
> closed. I've prepared a quick and dirty example that should help you to
> reproduce the problem.
> > The example includes our OSGExt library that contains our specific class
> implementations of ClusterWindow and RenderServer. Additionlly there are a
> ClusterClient and a ClusterServer application based on the OSGExt lib
> included.
> > Usage:
> > - run startClient, startServer1, startServer2 from the run folder
> > - by pressing '1' or '2' you can disconnect either the first or the
> second render server
> >
> > By default the connectiontype is set to Multicast. Using this mode
> client and server freeze after one server has been disconnected. If you change
> the connectiontype to "StreamSock" (ClusterClient: line 105), the connection
> is still ok, after disconnecting one server.
> >
> > I'm sending the complete source code offside the mailing list.
> >
> > Hope this will help you to find the problem.
>
> yes, it is of great help, thank you! I believe I've found the problem:
> GroupMCastConnection keeps two additional vectors of SocketAdresses
> (_receiver and _waitFor) and the latter is used to determine which
> machine has outstanding ack packages. On a disconnect these vectors
> where not updated so that the connection was still waiting for ack
> packages from the disconnected machine.
> I've attached a patch that corrects this and makes your examples work
> for me. Would you mind giving it a try and letting me know if it fixes
> the problem at your end as well? Thanks!
>
> Cheers,
> Carsten
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
