IOT server - sync begin event

[Maróy Ákos]

Tommi,

I'm writing the C++ client to validate against your IOT server, and I
seem to be running a problem. With the Java client, the message sequence
is something like this:

client sends: join request
server sends: join response
client sends: inject request
server sends: inject response
server sends: sync begin
server sends: perception
server sends: sync end
...

now, with the C++ client, I get as far as the inject request / response
pair, but then the server does not send me the sync begin event message.

what triggers the sync begin event message? when testing with the Java
client, it seems to 'just be sent' by the IOT server..

sorry if this is some mistake in my C++ code...

Akos

[Tommi Laukkanen]

Hi

The objects are send after successful join and injection of avatar.
The location of the avatar is used to calculate objects in range which
are in turn sent to client in initial state synchronization. Could you
check the return values of the join and inject to see if they
succeeded. One possible reason is that the id of the injected avatar
object is not the same as avatar id in the join request message.

regards,
Tommi

[Maróy Ákos]

Tommi,

> The objects are send after successful join and injection of avatar.
> The location of the avatar is used to calculate objects in range which
> are in turn sent to client in initial state synchronization. Could you
> check the return values of the join and inject to see if they
> succeeded. One possible reason is that the id of the injected avatar
> object is not the same as avatar id in the join request message.

thanks, my mistake, works much better now..

Akos

[Tommi Laukkanen]

Sounds like C++ is proceeding nicely :)

[Maróy Ákos]

Tommi,

> Sounds like C++ is proceeding nicely :)

To give you a brief update:

- the C++ code works fine now on Linux, using the GNU C++ compiler, the
SUN C++ compiler and the intel C++ compiler

- it does not work on Windows, neither on MSVC or mingw32. there's an
issue with binding to a random UDP port - I have to investigate this

- it compiles on a MacOS cross-compiler, but have not tested it on Mac yet

Moyshe, if you want to give it a try on OpenSolaris, you're more then
welcome to do so.

if anyone who is a Windows person would want to take a look at the
Windows related issue, I'd be more than happy to give details on the
specifics on what is not working out. (it's a boost asio related issue)

as soon as Windows, Mac and OpenSolaris are made to work, we can do a
release I guess. the steps then would be:

- change the license to MPL
- determine what should be in a binary release. my guess is:
- the include files
- the compiled binaries for the major platforms
- generated documentation (doxygen)
- maybe a sample app source code?

for this time, I can compile and generate binaries for Linux 64 bit,
maybe 32 bit, Windows (MSVC and mingw32), and MacOS. in the long term,
it would be best to pick 'tier 1' targets, that are supported by MXP,
and accept contributed binaries from the community. for 'tier 1'
targets, the best would be to have continouos integration set up - that
is, hudson, doing compilation, testing, etc. I already have this running
for Linux - Tommi, you said you have a Windows server that could be
running hudson as a slave, and could take care of Windows compilation /
automated tests. the question is if we can get a MacOS server as well
somehow. (MacOS is not that easy to set up in a VM like VirtualBox or
VMWare)

Akos

[Tommi Laukkanen]

You are doing magnificent job with the c++ implementation and cross
platform support. It is really valuable thing that the library can be
used on all those platform. Cheers to that :)

-tommi