I am looking to get UPnP device discovery, description done in Javascript - either in standalone browser environment or in NodeJS
Towards that, I tried below two solutions but both did not work for me. Details -
1]NodeJS bases:
https://www.npmjs.com/package/upnp-client
After correcting few typos in the example app, and running it in node (My nodeJS is running under X-Ubuntu Virtual Machine inside Virtualbox)
I get below errors on running the upnp-client example app
dgram.js:399
throw new errnoException(process._errno, 'addMembership');
^
Error: addMembership EBADF
at new errnoException (dgram.js:457:11)
NodeJS version: v0.10.25
Upnp client api: 0.0.1
2]Under Browser(Chrome/IE)
https://www.npmjs.com/package/upnp-client
None of them at the versions I have supported the navigator.getNetworkServices API which seems to be needed for this library
How can i get UPnP device discovery working in Javascript?
Any other solutions or pointers to resolve above errors/workarounds appreciated.
UPnP uses TCP/UDP packages for advertisement/discovery/etc. And since browsers cannot open network sockets, the short answer is: No. We can't use UPnP in a browser at the moment.
The only glimmer of hope is the Network Service Discovery, which is still in development phase in most of the browsers. In Chrome for example you could enable it using chrome://flags/#enable-experimental-web-platform-features, and then would be able to do something like this (from W3C draft):
function showServices( services ) {
// Show a list of all the services provided to the web page
for(var i = 0, l = services.length; i < l; i++) console.log( services[i].name );
}
navigator.getNetworkServices('zeroconf:_boxee-jsonrpc._tcp').then(showServices);
Related
I have a weird case.
I use chrome 75 for Mac OS.
When I push code in console some page
if ('caches' in window) {
console.log(`cache is supported`)
}else{
console.log(`cache is not supported`)
}
as a result I see that this is supported but I have local server on 8080 from vue. When I call it there it return that cache doesn't exists.
When I export vue cli code as production still cache is not supported in window.
Any ideas why? Thanks in advance for any hints.
I hava a java program with two buttons, one for chrome and one for firefox. I press one of them, and the browser starts at some particualar location on the screen and with smalles size.
i have try running terminal commands, something like this
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --profile-directory="Default" --app="data:text/html,<html><body><script>window.moveTo(198,60);window.resizeTo(1167,708);window.location='https://stackoverflow.com';</script></body></html>"
And it works, but only for chrome. I want at least chrome and firefox on both windows and linux.
Searching a little I have come across other solution. Running javascript on java, somethig like:
ScriptEngineManager factory = new ScriptEngineManager();
ScriptEngine engine = factory.getEngineByName("JavaScript");
engine.eval("window.open('https://stackoverflow.com')");
engine.eval("window.resizeTo(800,600)");
But Im getting compilation errors:
ReferenceError: "window" is not defined in <eval> at line number 1
And I don´t know whats going. Ideas?
For Windows, you can do something like this using Runtime:
Runtime rt = Runtime.getRuntime();
rt.exec("C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe stackoverflow.com");
I believe that you can do something similar for Google Chrome. I took a look to a code I implemented in the past for Chrome and it was a little different, but previous approach should work as well:
Runtime rt = Runtime.getRuntime();
rt.exec(new String[]{"cmd", "/c","start chrome http://www.stackoverflow.com"});
If you would like to do it for a Linux based OS, then you can use Runtime as well:
Runtime rt = Runtime.getRuntime();
rt("/usr/bin/firefox -new-window http://www.stackoverflow.com");
I remember I got some references from this page:
https://www.mkyong.com/java/open-browser-in-java-windows-or-linux/
Hope it can help you.
ScriptEngineManager runs the script on server side. window is a client-side object, you can't access it from server.
in another word since you are not executing your script in a browser, the window object is not defined.
You can try this way to open a website on your default browser of the operating system:
Desktop desktop=Desktop.getDesktop();
URI url = new URI("http://somewhere");
desktop.browse(url);
to open a non-default browser in Java you should use Runtime.exec()
for Windows OS try this it worked for me:
String browserPath = "C:/Program Files/Mozilla Firefox/firefox.exe";
String url = "http://somewhere";
try {
String[] b = {browserPath, url};
Runtime.getRuntime().exec(b);
}
catch (Exception exc) {
exc.printStackTrace();
}
for further information on how to use Runtime.exec() on others OS read here
I've been trying to solve the following problem for a few days now, and it's been driving me absolutely crazy.
I have a (1.2) meteor application, deployed at http://some.application.com:3000. It works great, and does what it is supposed to do. The application uses several packages, the ones that I think are related to this issue are autoupdate and the accounts package (which loads its own bunch of stuff).
Our directive is to turn this webapp into an android app, something we've been told meteor can do "quite easily". On the surface it seems like it's a simple case of meteor run android-device --mobile-server http://some.application.com:3000 --settings settings.json --verbose, however this doesn't do what I expect it to do.
Meteor decides to do the DDP connection on 10.0.2.2 (for whatever reason), and no matter what env variables I set I end up in the same situation.
It's important to note that the application has not been written using the DDP.connect(url) method anywhere [docs], so everything relies on the primary DDP connection (which I suspect might be one of the bigger causes of our problem).
For the record, here is my startup script. I got pretty desperate and added many, many env vars, and haven't had any luck for any combination thereof.
#!/bin/bash
export AWS_REGION=xxx
export AWS_BUCKET=xxx
export MONGO_URL=mongodb://some.application.com:27017/application
export QUEUE_ADDRESS=http://some.application.com
export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=xxx
export ROOT_URL=http://some.application.com:3000
export DDP_DEFAULT_CONNECTION_URL=http://some.application.com:3000
export MOBILE_DDP_URL=http://some.application.com:3000
export MOBILE_ROOT_URL=http://some.application.com:3000
# Let's go
meteor run android-device --mobile-server http://some.application.com:3000 --settings settings.json --verbose
Running it locally, on mobile or desktop, (via localhost:3000 with port forwarding, or any other internal IP (10.x.x.x, 192.x.x.x) works absolutely fine. It even works with the remote AWS, Queue and DB.
According to all the documentation the --mobile-server switch should sort things out. It doesn't. I've tried it with and without an =, wrapped in quotes, all possible ways of defining it.
Looking at the <head> of my document I see the following code getting injected
__meteor_runtime_config__ = JSON.parse(decodeURIComponent("%7B%22meteorRelease%22%3A%22METEOR%401.2.0.2%22%2C%22PUBLIC_SETTINGS%22%3A%7B%22verifiedLogin%22%3Afalse%2C%22enableFacebookAuth%22%3Afalse%2C%22enableTwitterAuth%22%3Afalse%2C%22enableGoogleAuth%22%3Afalse%2C%22cdnUrlWithTrailingSlash%22%3A%22http%3A%2F%2Fdev.cdn.some.application.com%2F%22%2C%22ga%22%3A%7B%22id%22%3A%22UA-XXXXXX-1%22%7D%7D%2C%22ROOT_URL%22%3A%22http%3A%2F%2Flocalhost%3A3000%22%2C%22ROOT_URL_PATH_PREFIX%22%3A%22%22%2C%22appId%22%3A%228emj6c37j3fdoz5qmp%22%2C%22accountsConfigCalled%22%3Atrue%2C%22autoupdateVersion%22%3A%222b3acf7aa3ddef802ddf661d3b3986319aad5122%22%2C%22autoupdateVersionRefreshable%22%3A%22b00197cdb5345434d03d9a2503906349ff7854e2%22%2C%22autoupdateVersionCordova%22%3A%223644168d46bc4597d0b2d8c39e366890f6725f52%22%2C%22DDP_DEFAULT_CONNECTION_URL%22%3A%22http%3A%2F%2Flocalhost%3A3000%22%7D"));
if (/Android/i.test(navigator.userAgent)) {
// When Android app is emulated, it cannot connect to localhost,
// instead it should connect to 10.0.2.2
// (unless we're using an http proxy; then it works!)
if (!__meteor_runtime_config__.httpProxyPort) {
__meteor_runtime_config__.ROOT_URL = (__meteor_runtime_config__.ROOT_URL || '').replace(/localhost/i, '10.0.2.2');
__meteor_runtime_config__.DDP_DEFAULT_CONNECTION_URL = (__meteor_runtime_config__.DDP_DEFAULT_CONNECTION_URL || '').replace(/localhost/i, '10.0.2.2');
}
}
The UrlDecoded version of that string is as follows
{
"meteorRelease": "METEOR#1.2.0.2",
"PUBLIC_SETTINGS": {
"verifiedLogin": false,
"enableFacebookAuth": false,
"enableTwitterAuth": false,
"enableGoogleAuth": false,
"cdnUrlWithTrailingSlash": "http://dev.cdn.application.com/",
"ga": {
"id": "UA-XXXXXX-1"
}
},
"ROOT_URL": "http://localhost:3000",
"ROOT_URL_PATH_PREFIX": "",
"appId": "jfdjdjdjdjdjjdjdjdjjd",
"accountsConfigCalled": true,
"autoupdateVersion": "2b3acf7aa3ddef802ddf661d3b3986319aad5122",
"autoupdateVersionRefreshable": "b00197cdb5345434d03d9a2503906349ff7854e2",
"autoupdateVersionCordova": "3644168d46bc4597d0b2d8c39e366890f6725f52",
"DDP_DEFAULT_CONNECTION_URL": "http://localhost:3000"
}
This is strange because I have no entries of localhost anywhere.
Booting the app tells me: App running at: http://site.some.application.com, but no connections are made in the network inspector.
Grepping through the code shows me that the only places where __meteor_runtime_config__ is mentioned is in the autoupdate package.
Further investigation lead me to this issue #3815 which linked to this fix, but after I implemented it (the changes to the autoupdate package) I was still faced with the same problem (although hot code fixes stopped coming through from my local machine)
Even more investigation lead me to believe that the remote DDP server could be changed like this, but unfortunately this solution doesn't work with Cordova.
I tried settings HTTP_PROXY as the comment "unless we're behind a proxy" in the <head> script lead me to believe this might be a quick fix, but I didn't have any luck with this.
I tried removing the accounts package, but have not had any luck in this regard.
Main Question Is there any suggested way to allow a Cordova wrapped Meteor application to connect to an arbitrary server, and allow a DDP connection to same?
The accounts package is (most likely) needed. I suppose auto-updates aren't thaaat crucial, although they do help in terms of not having to regularly release code to the various app stores.
Things I've tried:
Removing accounts package
Remove autoupdates
Modifying autoupdates to point to remote DDP
Using the remote-ddp package
Forcing __meteor_runtime_config__ overrides
Setting a proxy
Environment variables
And several other thousand things
Related issues (Going back to Jan 2015) are:
How can DDP_DEFAULT_CONNECTION_URL be set? #3852 - Shows difficulty in connecting to remote meteor servers, and touches on how the autoupdate package affects things.
Dont' start local server when using option --mobile-server #3727 - This shows a case of the --mobile-server becoming 10.0.2.2
Meteor mobile build is not changing DDP_DEFAULT_CONNECTION_URL #4396 - This shows an apparent fix, but this doesn't work for me at all
Ability to pass an alternative DDP connection to autoupdate #3815 - This shows the confusion that comes from the official documentation, and lead me to the autoupdate package "fix" that I linked earlier
MOBILE_ROOT_URL and MOBILE_DDP_URL are ignored on meteor build #4581 - This shows how meteor build ignores these env vars
Can't build mobile app with different DDP server #4412 - This shows others having difficulty with the same problem, with the response asking for PRs around the issue
Meteor Accounts only authenticates DDP, not HTTP #3390 - This shows that auth via meteor-accounts can only happen via DDP, and not HTTP
Built apps cannot connect to the given --server: they keep failing to connect #3698 - This shows other users having the same issue on iOS, although they do report having success with connecting to a local server, which I also have success with, but there is no mention of success with a remote server. The fix appears to be deploying through meteor to some-app.meteor.com but this isn't an option for us.
Contents of .meteor/packages
aldeed:autoform#=4.2.2
aldeed:collection2#2.5.0
aldeed:simple-schema#1.3.3
aldeed:tabular#1.4.1
autoupdate#1.2.3
biasport:facebook-sdk#0.2.2
blaze#2.1.3
check#1.0.6
edgee:slingshot#0.7.1
iron:router#1.0.12
jquery#1.11.4
juliancwirko:s-alert#3.1.1
juliancwirko:s-alert-slide#3.1.0
lookback:seo#1.1.0
matteodem:easy-search#1.6.4
meteor#1.1.9
meteorhacks:fast-render#2.10.0
meteorhacks:subs-manager#1.6.2
mobile-experience#1.0.1
momentjs:moment#2.10.6
mquandalle:jade#0.4.4
multiply:iron-router-progress#1.0.2
---
internal packages (one of which includes accounts)
---
reactive-dict#1.1.2
reactive-var#1.0.6
reywood:iron-router-ga#0.7.1
session#1.1.1
standard-minifiers#1.0.1
templating#1.1.4
tracker#1.0.9
underscore#1.0.4
underscorestring:underscore.string#3.2.2
utilities:avatar#0.9.2
I can provide the contents of my versions file if you feel that will help.
TL;DR - Is there any suggested way to allow a Cordova wrapped Meteor application to connect to an arbitrary server, and allow a DDP connection to same?
Any help or pointers around this issue would be much appreciated. Please let me know if there is any other information you may need to assist in this regard.
Many thanks
Issue On Github
Trying to use google's translate_tts as my fallback if the browser doesn't support speechSynthesis for my project.
Now I am having some trouble with getting the html5 audio working properly.
Been scratching my head and googling all day on why it wasn't working for me.
Then I came across some articles/forums saying that it's something to do with IIS. So I did a test code outside my site to see what happens, and was surprised this worked properly! But when using the same code in my original project which is running in IIS it doesn't work. AND it works when using IIS EXPRESS. I check the MIME types in IIS and mpeg and mp3 are there.
Even doing it in javascript doesn't work in IIS.
TextToSpeech.Audio = document.createElement("AUDIO");
TextToSpeech.Audio.src = url;
TextToSpeech.Audio.playbackRate = 1;
TextToSpeech.Audio.preload = 'auto';
TextToSpeech.Audio.volume = 1; // 0 to 1;
TextToSpeech.Audio.addEventListener('ended', function () {
//i have some code here...
});
TextToSpeech.Audio.addEventListener('error', function (error) { });
TextToSpeech.Audio.play();
Has anyone encountered this issue and happened to resolve it? Your help will be much appreciated, Thanks!
UPDATE: After some more googling, this might be because I am calling it from within my site hosted in IIS which has a proper hostname and my IIS Express runs the site in localhost:PORT which Google sees as noreferrer?
starting some time in the last few days, google seems to have placed a 'captcha' on this service and made it so that it can no longer be called by a server. so this may all be moot.
it used to be you could ONLY call it as a noreferrer, so i don't think noreferrer is your issue (or may be the least of your issues starting a few days back). one way to workaround the issue in fact was to add ref='noreferrer' to your link.
and this may be your initial issue: using wget, you had to use the -U Mozilla option which makes wget appear to be a browser. if you called the url without that, it didn't return anything. so if there is a way to make your IIS look like a browser when calling the google url, that may work.
this link google text-to-speech artile still does work in a browser, maybe that will help you use it the way you want.
however... starting july 28th, i get a '503 service not available' after using it for years with wget on my linux server. could be because it's metered and i've overrused it... i hope it comes back on. i only use it about 100x/day.
they always said it was 'not public' but it is widely used that way...
so that could be related if you're still trying to call it from IIS which i would think behaves similarly to calling it from a linux server.
I've been experimenting with WebSockets for the past couple of days and I'm having some mixed experiences with the new, very cool, technology. I've written a simple chat client that uses the latest release from HTML5 Labs, which I believe is the hybi-09 draft spec release. The client works great in Chrome (dev channel v14.0). Everything functions as it should. However, in every other major browser that natively supports WebSockets (FireFox (v6.0b) (Yes, I did turn on WebSockets functionality), Safari (v5.1)), it can't connect for some reason. Here's some of my client code:
$(document).ready(connect);
function connect() {
if ('WebSocket' in window) {
websocket = new WebSocket('ws://' + window.location.hostname + ':4502/chat');
}
else if ('MozWebSocket' in window) {
websocket = new MozWebSocket('ws://' + window.location.hostname + ':4502/chat');
}
else {
//not supported
return;
}
websocket.onopen = function () {
//do some setup stuff
};
websocket.onclose = function () {
//DOH
};
websocket.onmessage = function (e) {
//Do some stuff with e.data
};
}
and some (C#) server code:
static void Main(string[] args)
{
var host = new WebSocketsHost<ReverseService>();
host.AddWebSocketsEndpoint("ws://" + Environment.MachineName + ":4502/chat");
host.Open();
Console.ReadLine();
}
Like I said, it connects fine in Chrome and hits the .onopen function as it should. In FF and Safari, it goes straight to the onclose function and never connects. In FF, I get the following errors:
"NetworkError: 501 Not Implemented - http://localhost:4502/chat"
Firefox can't establish a connection to the server at ws://localhost:4502/chat
And in Safari:
WebSocket frame (at 4294967295 bytes) is too long.
The only thing I can think of is some kind of backwards compatibility issue. I believe Chrome 14.x implements the draft 10 spec of hybi WebSockets and I think FF 6 implements draft 07 or 08 and I'm not sure about Safari 5.1. If anyone has any insight as to what the problem is and/or how/if I can fix it, I'd appreciate the help. Thanks!
Chrome 14 and Firefox 7 (Aurora build, prefixed with "Moz" but enabled by default) support the HyBi-10 version of the protocol. Everything else that has native WebSockets support is still using the Hixie-76 version of the protocol.
There are server implementations that already support the HyBi protocol and many more will soon now that Chrome 14 has it natively. There are some that have support for both Hixie-76 and the newer HyBi versions of the protocol (libwebsockets, websockify). I'm not particularly surprised that Microsoft's prototype server implementation only supports one version of the protocol (since they were not in the game during the Hixie period).
Update:
Some server options:
libwebsockets - C implementation
websockify - My python implementation. websockify is a websockets to TCP socket proxy/bridge, but websocket.py is a generic websocket module.
Here is a .NET based (free) WebSocketServer that supports Hybi10 and the older protocols. Can be found at http://xsockets.net
or run the add to your project (MVC3) by using Install-Package XSockets in the Package Manager Console in Visual Studio 2010 ( Also think the 2008 will do Nuget now)
I uses one of the videos as help http://xsockets.net/Video/Index
Here is a WebSockets protocol test report listing conformance of Chrome 14 and Firefox 7/8 to specific features of the latest protocol spec.
The test suite is part of Autobahn WebSockets, a little project of mine that includes Python/Twisted-based WebSockets implementation, which can be used to write clients and servers.
Code is Apache 2.0 licensed and all on GitHub.