Create channel for addon and display messages on table

[Deleted]

That's great, thanks! :GetPushedTexture() is not working though, so I used a different texture. Going to the next step now

[Pelf]

What did you end up doing for the communication system?

I was thinking about how it could be done with equal peers. You could make focusing the edit boxes acquire a "lock" on that cell and broadcast that information so that the other clients could see that an edit is pending. But, clients that are activated during a lock wouldn't know about that and could try to acquire a lock on the same field. That could be solved by a lock queue, or...

If each client sent out a periodic heartbeat so that all of the clients would know who their peers are, then the acquisition of a lock could require: (1) a lock query to the other clients to see if it's possible to acquire the lock (if another client already has a negotiated lock on the same field, it would respond with that information) and when all clients respond favorably, then (2) a broadcast informing them that a lock has been acquired (they could update their UI for user-friendliness*). New clients would be unable to request a lock until one heartbeat cycle (until they've sent the heartbeat and received at least one heartbeat; no heartbeats? no peers; standalone mode). The information that each client has on its peers would need to be at least enough to be able to determine if a client is offline so that it can either be removed from the peer list or marked as inactive (and thus will not participate in lock negotiation). Once the edit is done, a broadcast informing the peers that the lock has been released would go out (but, again, this would just be for user-friendliness and display).

Well, either way, that was fun to think through .

* Purely cosmetic, though, as the full lock negotiation process would be required regardless of whether a client thinks another client has a lock.

[Deleted]

So far I have implemented a very simple version of the addon, to be able to test simple cases, and will come back later to add things like the lock system. As every client already stores a list of the clients participating in the discussion, I had thought of requesting to lock the cell and wait for n OK messages as reply, being n the number of participants. I find your idea of the heartbeat very interesting I will get back to you when I implement this (I'm planning to post a link to the whole addon when it's finished anyway), as I have also thought about just sending the request to the master and the master replying with OK or wait. This second idea matches with the rest of the communication system but I don't like it as much as the first one.

The only bad thing I see in all the communication system (even the simple one I'm currently using, where every message is sent to the client with the master copy of the data) is that in the end is a bit slow. Moreover, according to the documentation, you could be kicked out of the channel if your client sends too many messages (though I'm not sure about what they mean exactly by "many").

Thanks for the interest and help, it's very much appreciated

[Pelf]

If a pure equal peer system is possible, then I definitely prefer that, conceptually, to having to do the equivalent of this: http://technet.microsoft.com/en-us/l.../cc959896.aspx In the equal peer system, the only bottleneck is waiting for a response to a lock query. In that case, you could even apply some metrics in a later stage of development for just timing out lock queries. If a lock query times out, you would mark the peer client as inactive (as you would if it went offline) until another heartbeat is received from it. Under that system, it could scale pretty well, I'd think, because most communication is broadcast, and it's up to each individual client to process incoming broadcasts, but the work to do so is done on each client.

I was thinking something like every 1-2 seconds for the heartbeat. Possibly more (as much as 5?). That part doesn't really need to be that responsive as the first heartbeat would go out when the UI is just finishing loading and addons are coming online. By the time anyone actually opened up the window, several heartbeats would have probably been transmitted.

As for the query/response being slow ... I don't know how responsive addon communication channels are. I would assume they are as responsive as chat channels (they're more or less the same thing, right? just hidden). If the majority of messages are broadcasts, the only time an actual response is needed is when negotiating a lock. I can't imagine it would take more than a few seconds for all clients to receive the message, determine how to respond and do so. Could it?

[Deleted]

Thanks for the input! I'll check that later. So far I think your idea will work well but then I'll probably have to change the rest of the communication system. I'll think this through after finishing other stage of the UI.

The first stage allows players to edit text, so when a player joins, all the text is sent to him/her through the addon channel (which is as far as I know, a private channel that follows this protocol ). Then that client displays all the text in edit boxes. So there is a small delay between opening the window and getting the text displayed. And yes, it would take a couple of seconds to negotiate the lock and then write. I've tried the current addon with a slower connection and am a bit afraid that this kind of lag will make some players to not use the addon. But I'll guess we'll see

[Pelf]

Well, that brings up another point. Without an authoritative master, how do you make sure that every client has the same text?

The heartbeat could include a hash of the data, I guess. There are some hash algorithms included in http://www.wowace.com/addons/libcompress/ . Then, what do you do if you get a hash mismatch? I guess you could go with majority rules; but, how to respond and what to do...

I'm going to stop engineering your project. I'm having too much fun .

[Deleted]

I'm loving these posts Actually, this is part of my Bachelor's thesis (you guys will be in the acknowledgements section for sure!). The addon will be a tool to get data for a study, that's why I'm trying simple cases first. I did some research on communication protocols, concurrency issues, etc. but in the end we decided that was something to improve later, as some situations were not that likely and we have time constraints. I'm having a lot of fun with the development, though, and will try to improve the addon as much as I can even when it is "finished".
Thanks for everything! This is an awesome community!

[Pelf]

Yeah, that's well recognized. Premature over-accommodation is just as evil as premature optimization . Happy coding!

[Deleted]

Just make sure you leave a good way of implementing such a system. Not doing so will lead to many a headache (and unreadable code) later on.

[Deleted]

So in the end I'm working on the final stage now, since I have to defend my thesis soon, but we decided to redesign this a bit after that. I'll get to that later then. The final stage is the summary: after everyone has voted, everyone should see a summary of the votes.

I am making a basic mistake when adding elements to a table, but can't find why this method is wrong. I understand from the manual that this is how it should be done, so would really appreciate if you could throw some light on this

      addon.conflicts_active_testing[prefix].participants[participant] = ready
      print (#addon.conflicts_active_testing[prefix].participants)

I have to do something like that several times. Every time, if I print table[variable] I get the content I was trying to add (in the example, the value of ready). But if I print #table, I get "0". What I want to do use the string stored in a variable as a key for a new entry in the table.

Thanks!

[Deleted]

The count operator only counts numerically sorted entries.

> local t = {} t[1] = "value 1" t[2] = "value 2" print(#t)
2

> local t = {} t.key = "value" t.another = "another value" print(#t)
0

[Deleted]

Ah that's right, silly me! Then I'll guess I'll have to use pairs() and count like that.
Thank you!

[Pelf]

I just did that today, myself :|.