[omniORB] system time change on the server affects bidirectional GIOP callbacks?

[Sergiu Buciuc]

Hi All,

 

We have an IIOP.NET client that talks to an OmniOrb 4.0.7 server.

Bidirectional GIOP is enabled on both client and server.

 

When starting the client registers a callback object with the OmniOrb
server and expects the server to invoke the callback.

This works as expected until we change backwards 1 hour the system time
on the server machine (without stopping the server application).

If we start the client at this point, the callback from the server is
never received. Eventually the server call times out.

 

I've tried to track this down in the OmniOrb code.

When the server invokes the callback it first sends a "is_a" message to
verify the identity of the callback object residing in the client space.

 

0000  00 0e 0c 68 fa 30 00 13  20 95 da 17 08 00 45 00   ...h.0..
.....E.

0010  00 c6 16 64 40 00 80 06  b7 56 0a cd 0b d1 0a cd   ...d at ...
.V......

0020  0b 0d 04 38 04 cf a5 6c  f5 05 6e af 78 99 50 18   ...8...l
..n.x.P.

0030  40 87 53 ad 00 00 47 49  4f 50 01 02 01 00 92 00   @.S...GI
OP......

0040  00 00 03 00 00 00 03 00  00 00 00 00 cd cd 46 00   ........
......F.

0050  00 00 2f 63 32 33 32 31  39 31 65 5f 35 35 62 33   ../c2321
91e_55b3

0060  5f 34 34 38 33 5f 62 39  61 66 5f 32 31 32 33 61   _4483_b9
af_2123a

0070  30 38 37 66 63 30 39 2f  64 70 6b 65 31 75 72 38   087fc09/
dpke1ur8

0080  6f 73 77 67 6d 64 34 64  68 73 34 38 39 71 75 6b   oswgmd4d
hs489quk

0090  5f 34 34 38 2e 72 65 6d  cd cd 06 00 00 00 5f 69   _448.rem
......_i

00a0  73 5f 61 00 cd cd 00 00  00 00 cd cd cd cd 22 00   s_a.....
......".

00b0  00 00 49 44 4c 3a 69 78  69 61 2f 6e 65 74 6d 61   ..IDL:ix
ia/netma

00c0  6e 61 67 65 72 2f 50 53  57 43 6c 69 65 6e 74 3a   nager/PS
WClient:

00d0  31 2e 30 00                                        1.0.


 

Wireshark captures show the client answers back with the message:

 

0000  00 13 20 95 da 17 00 0e  0c 68 fa 30 08 00 45 00   .. .....
.h.0..E.

0010  00 41 01 8a 40 00 80 06  cc b5 0a cd 0b 0d 0a cd   .A.. at ...
........

0020  0b d1 04 cf 04 38 6e af  78 99 a5 6c f5 a3 50 18   .....8n.
x..l..P.

0030  f9 d1 2c ab 00 00 47 49  4f 50 01 02 00 01 00 00   ..,...GI
OP......

0040  00 0d 00 00 00 03 00 00  00 00 00 00 00 00 01      ........
.......

 

Now this message is never received by the server.

I've tracked down the problem up to file tcpconnection.cc , function
call tcpConnection::Recv, here's the interesting part of the code:

 

do {

.........................................................

 

      rx = select(pd_socket+1,&fds,0,&efds,&t);

#endif

      if (rx == 0) {

      // Time out!

#if defined(USE_FAKE_INTERRUPTABLE_RECV)

      continue;

#else

      return 0;

#endif

      }

.........................................................

 

    // Reach here if we can read without blocking or we don't

    // care if we block here.

    if ((rx = ::recv(pd_socket,(char*)buf,sz,0)) == RC_SOCKET_ERROR) {

      if (ERRNO == RC_EINTR)

      continue;

      else

      return -1;

    }

    else if (rx == 0)

      return -1;

 

    break;

 

  } while(1);

 

 

In this loop rx is always 0, which means timeout, and the client
response message to the "is_a" request is never read and the loop never
ends. 

In the good case when we don't change the time on the server, rx is 1
and the message is read ok.

As far as I can remember we didn't encounter this problem when we were
not using the bidir GIOP.

 

Any help is greatly appreciated, please let me know what other info
might be necessary.

 

Best Regards,

Sergiu

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080208/a3e2fed5/attachment.htm