[Opentnl-general] OpenTNL Failing to Connect

[boB G. <boB@Gage.net>]

Argh!   Hep me hep me!

I had some problems with my project crashing and I thought I'd be doing 
some good if I updated to 1.5.0.   Well, that may not have been the best 
idea, perhaps if I'd gotten my program stable before upgrading it would 
have gone better.

I've updated several (I think all) RPC calls that were using parameters 
that are no longer valid (ByteBufferRef, actually most __Ref types, ...) 
but am still having some serious issues.    I've added loads of debuging 
code (is TNLLogMessageV's) into the core TNL code to see what's going on, 
but so far it's a lot of data but no knowledge.

The problem is the client & server don't connect, though the connect 
arrangement with the master seems to go fine.

The gory details points are:
    -  Both client & server are sending and receiving punch packets.   Each 
packet received *is* what the other has sent (ie they aren't corrupted)
    -  The punch packets are being discarded at either end because the 
Nonces do not match
    -  Tracking the addPendingConnection() method shows that each is adding 
a pending connection with it's own nonces (ie not equal).
    -  The nonces used in the addPendingConnection() method are the ones 
being sent in the punch packets, but since client & server each have their 
own nonces, they do not match at either end.
    - For awhile, data passed as ByteBufferPtr into RPCs was not being 
transferred accurately, but that has been fixed (my bad usage).

I've attached the logs from one run.   Translating to OpenTNL jargon: Auth 
is the master server, Realm is the server, and Client is the client.

A possibly related, and truly odd, problem I had with the initial upgrade 
is that when I linked I got umpteen unresolved names -- everything in 
tnlMethodDispatch.cpp.   I triple checked, and the .o file is listed in the 
OBJECTS definition in the makefile, and even can be seen (seriously 
mangled) in libtnl.a using 'nm'.    BUT, the only way I got my programs to 
link was to explicitly link that one object file in addition to linking in 
libtnl.a

Any clues would be greatly appreciated.

Thanks in advance,
boB Gage