Intermud Grapevine Chat support

Hello folks,

I've completed basic integration with my Circle/TBA-based MUD with Grapevine to allow for gossip and tells to be sent between different games. Info about Grapevine itself can be found at grapevine.haus/

This is a modern and secure alternative to older intermud systems like i3 that uses TLS and web sockets. My implementation does require you compile in C++. Details available here: github.com/halimcme/worldofpain

Thanks,

-Blizzard

Thanks for this, but seems to be lacking in thread safety I think? The on message callback runs in another thread and the message handler functions are touching your main thread resources (descriptor_list, character_list). Are you seeing issues from this? I'm seeing intermittent segmentation faults.

I haven't had any issues like that related to threading. I haven't really done any coding with threads before. Would it make a difference that my descriptor_list and character_list are C++ lists of pointers?

Maybe I'll have to look at rewriting it with a web socket library that doesn't use threads. This one just looked easiest to write code for, after checking out several.

or maybe I can implement locking around the part of the game loop where these data structures may be modified. I'll read up on that.

I added
// lock threads for the main loop
std::mutex mtx;
mtx.lock();

and
// unlock the thread
mtx.unlock();

at the beginning and end of the game loop and it appears to work still. I'll let it run under gdb for a bit.

Turns out the segfaults were an unrelated issue, but yes, I think you'll need to add some locking for thread safety. For instance, say a broadcast message comes in on the websocket thread. You handle it in GvChat::eventBroadcast, doing send_to_char to everybody, but what if your main thread is also doing a send_to_char to the same player at the same time? 2 threads writing to the same memory at the same time is no bueno :).
Easiest way to handle it I think is to put the incoming messages in a queue that you periodically come and handle from the main thread. I thought you might have had that in mind since you added _receivedQueue (though unused). You use a mutex to lock access to the queue. When new message comes in, lock the mutex and add it to the queue. Somewhere in your main thread (game_loop) you call into a function that locks the mutex and processes all the queued messages. Anyway, that's the general idea and seems to work for me. However, this introduces a new wrinkle, which is that (at least in our game) the main thread sleeps when nobody is logged in, so after a while of not answering the heartbeat events, grapevine connection will drop. Probably makes most sense to close connection from our end before we go into the "no player" sleep, and reconnect once somebody logs in.

Just to note, there are some other bugs in there as well. For instance, doing gvtell with no arg crashes.

Thanks for the advice. I'll implement the queue approach. That function was probably leftover from the example code I started with haha. For now, mutex locking the entire game loop doesn't seem to cause any problems but that sounds cleaner. I think I'll process it even when sleeping so the game still shows as online on the Grapevine site. Most other implementations do this. This project has delved into a lot of coding areas I've never worked with before. :)

I've got the queue approach implemented and updated the documentation on it. I've decided to go with disconnecting from Grapevine when sleeping and then reconnecting as I don't see any other way to do it without changing major stuff like replacing select sleep with something else. The gvtell crash is also fixed. Latest code uploaded to github.com/halimcme/worldofpain with integration docs updated in GRAPEVINE.md, with the comm.c changes being the major things needed.

Welcome for feedback on any other bugs, suggestions or improvements. I might eventually put in things like fancy formatting, colors and paging but I want the core of this stable first.

Nice, looks solid. Good call on queuing the log messages too, I didn't think about that.

I just posted an update to the code.

I've removed the Guid object and gvMessage string from char_data and implemented an action map in the GvChat class that stores guids and associated players and messages. I am using a char_data pointer in the map, but I added a function to remove all actions for a player if they sign out or otherwise get extracted.

I also added color support to most functions, and moved where the log queue gets processed to the start of the game loop. GRAPEVINE.md has been updated with current details.

Forgot to mention, I also added support for Grapevine heartbeats while sleeping, making the GvChat class aware of when the mud is sleeping or not and responding differently based on that. I also moved processing of the log queue to the beginning of the game loop.