C++ pipes problem

[klusbert]

Hello tp!
I really need some from you guys.

I have a project a .net program that uses a injected.dll(c++)

I have tested out 2 diffrent ways of sending pipedata to my .net app.

//method1
inline void PipeWrite(Packet* p)
{
	CreateThread(NULL, NULL,(LPTHREAD_START_ROUTINE) PipeWriteProc ,(LPVOID)p,0,NULL);
	//PipeWriteProc((LPVOID)p);
}
void PipeWriteProc(LPVOID lpParameter)
{
	EnterCriticalSection(&PipeWriteCriticalSection);
	Packet* packet=(Packet*)lpParameter;
	WriteFileEx(pipe, packet->GetPacket(), packet->GetSize(), &overlapped, NULL); 	
	LeaveCriticalSection(&PipeWriteCriticalSection);
}

This method works good, besides it misses hooked packets sometimes.

inline void PipeWrite(Packet* packet){
//Method from tugbot
	if ((*(DWORD*)Consts::Connection) != 8) return;
	WriteFileEx(pipe, packet->GetPacket(), packet->GetSize() + 2, &overlapped, NULL);
	delete packet;
}

This method is a ripoff from Tugbot. And works well until I relog. Then the client crashes. I Cannot understand why.

I know that Darkstar has encountered this problem before, I can see that in his code.

This project is for an old client version.

[jo3bingham]

TibiaAPI has the same issue. It only affects Windows 7+, if I remember correctly. XP and Vista didn't have this problem. Also, the crash only happens if you create the pipe before login, and attempt to login, or you attempt to relog or switch characters. Basically, it happens upon login. And, again, if I remember correctly, it'll happen as long as there is a pipe present. Whether or not you've written anything to it.

One way to bypass this is to only create the pipe when the player is logged in, and destroy it upon logout. Or, preferably, use a different type of IPC (shared memory, sockets, etc.).

[DarkstaR]

That code is so bad, from before I understood C++ and some of it is just badly modified TibiaAPI. I bet if you re-write the pipes from scratch without passing around raw pointers and deleting them in a hidden scope level and doing all this other weird shit, it will go away.

[klusbert]

Yep it is code from tug, and Tibia api. I Will take some time to leran c++ better. Becouse all c++ i "know" is from those two projects. Thanks

@jo3
I thought about other IPC for some time. Maybe sockets?

[DarkstaR]

Yep it is code from tug, and Tibia api. I Will take some time to leran c++ better. Becouse all c++ i "know" is from those two projects. Thanks

@jo3
I thought about other IPC for some time. Maybe sockets?

I would advise against sockets for IPC, as it becomes messy and unmanageable and firewalls will hate you. Maybe use shared memory, a global mutex for sync, and global events for signaling.

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

[szulak]

I would advise against sockets for IPC, as it becomes messy and unmanageable and firewalls will hate you. Maybe use shared memory, a global mutex for sync, and global events for signaling.

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

Alternatively, you might take a look on boost::interprocess::message_queue (http://www.boost.org/doc/libs/1_55_0....message_queue) Using global mutex as a synchronization mechanism would be the same pain in the ass, like sockets - you must have two global mutexes (for reading and writing), it's gets even more complicated if you want to support multiclients. Use pipes or message_queue. Lastly, there is one more option which comes to my mind - Windows RPC - it's a bit of work (you must design your own protocol for message massing *idl* both for client -> server and server -> client), wrap it in any reasonable class - but once you have it, using windows RPC is pretty sweet - it's just a function call in one process, and handling this call in second process.

[DarkstaR]

Alternatively, you might take a look on boost::interprocess::message_queue (http://www.boost.org/doc/libs/1_55_0....message_queue) Using global mutex as a synchronization mechanism would be the same pain in the ass, like sockets - you must have two global mutexes (for reading and writing), it's gets even more complicated if you want to support multiclients. Use pipes or message_queue. Lastly, there is one more option which comes to my mind - Windows RPC - it's a bit of work (you must design your own protocol for message massing *idl* both for client -> server and server -> client), wrap it in any reasonable class - but once you have it, using windows RPC is pretty sweet - it's just a function call in one process, and handling this call in second process.

Actually, come to think of it, you don't even need mutexes. You need two shared memory buffers, and two global events (assuming a 1-to-1 injected dll to bot ratio).

Using event e1, the injected dll signals a new buffer in shared memory s1. The dll then waits for a signal from e2 meaning that the message was received successfully, with any additional data in s2.

[klusbert]

I played some with this method.
http://pastebin.com/wYBiyy19
It's a ripoff from pinvoke.

In my server I setup like this.

   private void Form1_Load(object sender, EventArgs e)
        {
            WorkingThread = new Thread(new ThreadStart(ReadPackets));
            WorkingThread.Start();
        }     
        private void ReadPackets()
        {
            GlobalEvent = new NamedEvent("Lada");
            while (true)
            {
                GlobalEvent.Wait((int)NamedEvent.INFINITE);
                MessageBox.Show("GotMessage");// now we can read the data we want
                GlobalEvent.Pulse(); // tell the event that we are done what we want

            }
        }

My client looks like this:

   NamedEvent GlobalEvent;
        private void button1_Click(object sender, EventArgs e)
        {
            GlobalEvent = new NamedEvent("Lada");
            GlobalEvent.Set();

            GlobalEvent.Wait((int)NamedEvent.INFINITE);
            MessageBox.Show("read complete");
         
        }

I will need two of this events and shared memory to make it work like it should, And this code should be verry easy to translate to c++. Thanks darkstar.