4

I have an issue that's driving me mad. I have successfully been able to connect my teamviewer session from a browser uri to my required remote resource. I achieve this by using the following uri command in the browser address bar (in reality, it's a button click in html):

  • teamviewer8://remotecontrol?connectcc=123456789

Although this connects perfectly as required, it presents an issue that I need to address.

The problem

If the connection isn't yet open, the teamviewer session is initiated and the window pops up in my second monitor as required. All good. However, if the session is already running and I initiate a subsequent request to the same uri, a new session is spawned and I'm left with multiple, duplicate session windows. This is both resource hungry in the long run and undesirable in practice.

My ideal solution

Ideally, I'd like the process to function such that a new session is called if it does not have the given id already running. If an earlier session with that Id is running, than I'd like to find a way to bring that into focus, rather than having teamviewer new up a new session.

What I already know

I know that this is possible as the teamviewer console does just this if you attempt to initiate a second session against an already running id. Using the teamviewer console is not an option as I've developed a web based desktop solution that requires the sessions to be kicked off via button clicks inside the UI (the id's are stored in my own db).

The app that I have created has the potential to literally open hundreds of duplicate windows as I'm looking at many processes across a small range of id's over a concentrated period of time, thus a solution is urgently required.

The bottom line

Is it possible to add a parameter to the uri to tell teamviewer not to create a new session. Is there a simple switch that I'm missing that will address the issue??

Thanks for reading...

[edit] - although unlikely to have any bearing on things, I'm using asp.net mvc for the application. I add this info as it could well be that the http pipeline is adding/cacheing something that teamviewer interprets as being a uniq identifier.

[Update]

After careful consideration and fruitless searching, I decided to create my own proxy application and register it with a protocol of my own choosing. This proxy app is called with the same parameters as the teamviewer protocol, i,e, arb://remotecontrol?connectcc=123456789. My little app has an internal dictionary and does a search against window titles into the dictionary. if it finds a match, it brings the window into focus, if it doesn't, it does a Process.Start() using the teamviewer protocol and then adds the data to the dictionary. there are some other checks too, but this works fine so far.

I used these links for initial inspiration:

Hope this helps anyone else out there that needs to workaround this kind of scenario in whatever situation demands it.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
jim tollan
  • 22,305
  • 4
  • 49
  • 63
  • I've never developed anything involving TeamViewer, but have you checked the [API documentation](http://downloadeu3.teamviewer.com/integrate/TeamViewer_API_Documentation.pdf)? There's a section there all about session management. – John H Mar 06 '14 at 14:37
  • hi john, yes, i've looked at the restapi in some detail. unfortunately, it is dedicated to managing users, groups, meetings etc and is not a programatic api to invoke functionality as such. my dilema is centred around the invocation of the tv session via the browser link. it all works fine as i'd mentioned, but does spawn multiples on the same id, rather than reusing and bringing into focus. to say it's frustrating is an understatement as finding the actual commandline required was nothing short of spectacular luck as there's not a lot on the web related to this. – jim tollan Mar 06 '14 at 14:41
  • to add further to the above comment. although I could create a small desktop sentinal app that could monitor the creation of teamviewer windows and then bring into focus or kill duplicates, this is not my route of choice, even tho it would serve the purpose of cleansing the dupes!! – jim tollan Mar 06 '14 at 14:56
  • +1 btw and you're right; there really isn't very much information about this. I tried googling for `teamviewer "connectcc"` and managed to find [this strings analysis](http://totalhash.com/analysis/358e35565e7686f5433125a6dba56e05975bbb40) of the TeamViewer executable. It's a complete shot in the dark, but there are several strings in there which you might be able to use to specify the actual session directly - maybe that would prevent the duplicates. They are: `connectsid`, `session` and `sessionID`. Like I said, it's a wild guess, but there's really not much to go on. – John H Mar 06 '14 at 15:21
  • I should mention that I haven't read the whole analysis of that file, so it's quite possible there are other (potential) parameters you can glean from reading it. – John H Mar 06 '14 at 15:23
  • john, i did see that link earlier when reviewing, tho admit that i didn't go too deep into it. i did try those params however without succees. thanks for delving tho, it is there somewwhere i'm sure. (i've also emailed teamviewer support in germany, but they are notoriously slow in responding) – jim tollan Mar 06 '14 at 15:30
  • No problem. :) I hope you find a solution. (I'd like to know now, too.) – John H Mar 06 '14 at 15:33
  • 1
    john - i may have to go down a custom protocol path and have a little proxy app that contains a dictionary. this app will then either call the teamviewer command with the parameters, or will invoke the previous window. really need to do this fast, so not the most elehgant, but possibly the most pragmatic. see http://msdn.microsoft.com/en-us/library/aa767914%28VS.85%29.aspx for details – jim tollan Mar 06 '14 at 16:28
  • Thanks for the update. Glad you got something working. – John H Mar 06 '14 at 17:37

0 Answers0