Forum


Notice to all users

We are migrating towards a new forum system located at community.teamspeak.com, as such this forum will become read-only on January 29, 2020

Results 1 to 5 of 5
  1. #1
    Join Date
    October 2012
    Location
    Germany
    Posts
    553

    Plugin Communication

    Communication over the server

    So, I'm experimenting with 3D Audio Positioning / VR and would need to send positioning info.

    I have some rare events, and, obviously, frequent ones: Position updates.

    So far, as I see it, are two options:
    1) using sendPluginCommand to push the info
    2) using CLIENT_META_DATA to enable pulling

    I got some headaches how to be a nice player here.

    2) CLIENT_META_DATA seems to have the issue, since it's rather intended for sdk users than plugin authors, that there needs to be a convention (like "pID=pluginId"...stuff.../pluginId" or sth.) to enable multi plugin usage by string parsing. So far, from the sources I have seen, no plugin tries to - therefor any plugin that uses this yet is incompatible to any other at this point.

    1) sendPluginCommand seems to be the better choice in this regard, since it utilizes the pluginId and avoids the above problem.

    However, with the theoretically ideal frequency of multiple updates per second, I'm worried about hitting spam protection. I am aware that details need to be secret, but I would appreciate some guidance here to not be a troublemaker. I see anti-flood now only triggers ignore commands instead of bans, but I can't be sure to for example kill rare more important user commands (ptt...) by this, can I?

    Local inter-plugin communication
    While I don't need this as urgent as communication over the server, I think we might as well cover this topic here and now, too.
    First, let's see if it is desirable. I do see several usage scenarios. For once, specialized plugins would be enabled to "block" features of generalized ones. Quite a leap for plugins, imo, would be that plugins would be enabled to act as libraries for other plugins. Quite often, there's the request for a certain plugin feature, but "it would be cool to see it on my G15 / ts3overlay". Implementing such in any plugin of its own is obviously not desirable.
    Those display plugins would be able to provide a public API.

    Currently, gaining access to other local plugins isn't really comfortable afaik, since one needs to use plattform dependant handling as far as I know. Or maybe it's a lot more straight forward, and I'm just not aware of it?
    If one could get the pluginId of other plugins, which, afaik, one cannot, one could use sendPluginCommand to send to oneself as a workaround. Depending on the implementation of this function, it'd generate useless traffic though.

    Ideally, imo, it'd look sth. like
    Code:
    (*sendLocalPluginCommand)(uint64 serverConnectionHandlerID, const char* pluginID, const char* command, const char* senderPluginId, const char* senderPluginName, const char* returnCode);
    serverConnectionHandlerID being optional, mostly for consistency.
    pluginID would need to be replaced by pluginName if there's no way of getting the id.

    Alternatively, one could, instead of extending the api, internally add a check to requestSendServerTextMsg for startsWith("/") and just trigger the command consistently with the client ui?

    Any input is welcome.
    Last edited by Philosound; February 28th, 2013 at 01:49 PM.

  2. #2
    Join Date
    September 2012
    Posts
    6,079
    sendPluginCommand is definitely the way to go here. As for triggering the flood protection you can easily run tests yourself by just spamming a bunch of them in a loop and you should quickly see if it triggers flood protection.

  3. #3
    Join Date
    October 2012
    Location
    Germany
    Posts
    553
    Well, it does
    The question is, how to move forward from here.
    Technically I may be able, if it's universally allowed permission wise (didn't check yet), ask the servers on connection about its individual anti flood settings and tune the sends to stay below it using an empirically determined point assigment, leaving a little headroom for user interactions. It'd be an error prone, let alone uncomfortable, time intensive way that has some fishy feeling...

    I figured therefor, since this command hasn't been used in a lot of plugins that way (I'd just guess since that arma2 mod reads out the memory, it'll get all positions from there), the team may have had only rare events ("Playing in Winamp: The Song!") in mind assigning the point value for this action. So, once the initial no-punshing-holes-in-anti-flood impulse has settled, if someone might just take out his pocket calculator and give this a look, I'd appreciate that.
    My beta users have hit the threshold with 0.6s on server default settings, it's working with 2s. Before I go hunting anti-anti-flood strategies and values, keeping in mind most non-default settings will likely be harsher than softer, I'd like to ask for input on this matter as in consequence positioning data would end up having "lags" in the users reception even when I manage to throttle the frequency below the threshold, and "ask your server admin to increase those values" isn't exactly a satisfying answer to give to users (in consequence, to achieve positional audio transmisssion having to go independent-p2p which I'd like to avoid at nearly all costs).

  4. #4
    Join Date
    September 2012
    Posts
    6,079
    come to think of it, it makes perfect sense to be covered by the flood protection as it goes through the server and could cause higher load and increased traffic. Sending stuff several times a second constantly is exactly what the flood system is supposed to prevent.
    We will have to discuss whether something can be changed here, but even if something changes it's unlikely that you'd be able to send commands constantly at the high frequency you desire.

  5. #5
    Join Date
    October 2012
    Location
    Germany
    Posts
    553
    In the meantime, I have optimized the communication by reducing some spikes on channel entering caused by a call and response initialization approach. The network code should be as efficient as it gets now, so aside from dynamically adjusting the frequency by server anti flood settings I'm out of optimization options.
    I do get a still ok user experience on default server settings, I'm not insisting on a theoretical optimum As long as I can stay below a user noticeable audio offset, I'd be fine. It's just that positional data by nature requires more anything than user interaction, which is also why this use case is bringing it into the context of anti flood, traffic (though compared to audio data it shouldn't make a noticeable difference in traffic, but I understand providers may calculate hard on such things) and such in the first place
    At the moment, one compromise that springs to my mind would be to have pluginCommands, as they're not necessarily a user interaction, to have them on a separate tick counter, so that no permission or anything would need to be added, while hitting the threshold may only forbid succeeding pluginCommands (instead of ptt, channelmove etc). So one would get an error hitting it, and needed to act accordingly, but without causing trouble for the user, so it'd still be adviseable to dig into those individual server settings and adjust the frequency to avoid that from happening. However, at this point one wonders if there may not be a better way, like having those things automagically throttled client side, dunno. Overall, that's really more your field of expertise than mine.

    Off topic addendum:
    Before I may or may not dig into those server values, I'm going to research how to actually take a client "out of" 3d positioning, bringing it back to the middle and staying there when one leaves a world. As soon as I found a poor test subject, I'll be trying out a Vector of 0.0f,0.0f,0.0f and NULL. If you happen to know, dropping a line would speed things up I'll eliminate this addendum once I finished this task myself.
    Last edited by Philosound; March 14th, 2013 at 12:53 PM.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Plugin communication
    By nonameShadow in forum Client Plugins / Lua Scripts
    Replies: 1
    Last Post: September 29th, 2015, 09:00 AM
  2. [Problem] Plugin for Serial Communication (RS232) to activate PTT
    By kubax in forum Client Plugins / Lua Scripts
    Replies: 8
    Last Post: May 13th, 2013, 10:10 AM
  3. All way communication
    By JoeDSileo1988 in forum Suggestions and Feedback
    Replies: 1
    Last Post: December 27th, 2009, 09:50 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •