ObjectStreamWrapper problems.

[CheezBoiger]

If the C++ code in CommProtocol works fine. Then it's the problem in the C++CLI mode code. The Comms node in C# is properly getting the send and receive nodes, as well as properly calling the callbacks as well, but we have a small problem.

The ObjectStreamWrapper, when returned, is not properly getting the information. In this case, the program is saying that it's suffering a buffer underflow.

My theory may be that the header is not being added into the packet in C# wrapper for object stream. I'll test this out. Still trying to find the issue.

[MichaelWallace30]

I can look at it tonight and see whats going on.

[CheezBoiger]

It's not the ObjectStreamWrapper. It's in AbstractPacketForwarder, specifically this function:

void AbstractPacketForwarder::pack(ObjectStream& obj) {
  // temp object.
  ObjectStream temp;
  CommPointer<ObjectStream> ptr = temp;
  ObjectStreamWrapper^ wrapper = gcnew ObjectStreamWrapper(&ptr);

  owner->Pack(wrapper);
  // ObjectStreamWrapper will delete after this, along with ObjectStream, so CommPointer 
  // saves ObjectStream from this. Problem now is that We need to copy the values in here to
  // obj in order to properly send the stream into our C++ lib.
}

[CheezBoiger]

Actually, yea it might be the ObjectStreamWrapper.

[CheezBoiger]

It's not the CommPointer, but ObjectStream is causing buffer underflow.

[MichaelWallace30]

Objectstream temp doesnt look like a pointer

[MichaelWallace30]

Looks like temp goes out of scope

[CheezBoiger]

Oops yea you are right on the temp. It needs to be a pointer otherwise it gets constructed on the heap again lulz.

[CheezBoiger]

Ok so the problem is that it is out of scope. Nothing is wrong with the ObjectStreamWrapper.

[CheezBoiger]

At this point, i need to figure out how to transfer information from ObjectStreamWrapper to obj.

[CheezBoiger]

then it should work perfectly. That's my theory...

[CheezBoiger]

@MichaelWallace30 I might need to create some setters in your ObjectStream if that's ok with you?

[CheezBoiger]

Oh crap nevermind you already have some.

[CheezBoiger]

Ok I partially fixed the problem. Now the problem lies in the Callback part. I'll see what's going on.

[CheezBoiger]

Ok i see the problem now. It's working, but it's not passing the unpacked packet into the callback.

[CheezBoiger]

We'll, it is, but it's not passing the ABSPacket that was unpacked before.

[CheezBoiger]

The header passes through just fine, but the AbstractPacket is left in the cold lulz.

[CheezBoiger]

i hate this so much... there is no way to pass the unpacked ABSPacket into the callback. in C++.

[MichaelWallace30]

Is it a polymorphism issue?

[CheezBoiger]

Yea, pretty much. If we wamt this to work, we need to make a custom Comms node in C# instead of wrapping the native one.

[CheezBoiger]

A custom C# version one will make it easier

[CheezBoiger]

I'll see what i can do.

[MichaelWallace30]

Ok I assumed thats our only reasonable option.

[CheezBoiger]

Yea, The native Comms cannot be wrapped. Instead we'll make a C++CLI version.

[CheezBoiger]

But in order to do that, I have to first create the CommNode C# wrapper.

[MichaelWallace30]

We can still wrap low level protocols.

[CheezBoiger]

indeed, breaking the problem down to pieces first, lulz.

[MichaelWallace30]

So Im not sure if I should keep the communication buffers as uint8_t* and just use our ObjectStreamWrapper natives ObjectStream or something else. My concern is you goal of making Comms a C# class which can really only use Byte arrays. So should I convert Byte[] to uint8_t* at some point or should I just leave all network wrappers as uint8_t.

[CheezBoiger]

The data from C# should still hold and pack correctly into our native ObjectStream without too much issue, so the buffers will be ok. Data types should get worked out from within CObjectStream, unless you think otherwise.