Sergiu Buciuc
2008-02-08 22:02:36 UTC
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 ***@...
.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 ***@...
........
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
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 ***@...
.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 ***@...
........
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