Giter VIP home page Giter VIP logo

engine.io-client's Introduction

engine.io-client's People

Contributors

3rd-eden avatar adrai avatar albertyfwu avatar alexlmeow avatar asdfryan avatar binlain avatar cadorn avatar crzidea avatar darrachequesne avatar defunctzombie avatar dependabot[bot] avatar digawp avatar dvv avatar kkoopa avatar lpinca avatar mokesmokes avatar mokesmokes2 avatar nkzawa avatar paradite avatar rase- avatar rauchg avatar raynos avatar ruxkor avatar sanemat avatar sergioramos avatar stash avatar sweetiesong avatar timmak avatar tj avatar tootallnate avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

engine.io-client's Issues

Improve `parseUri`

localhost:3000 should work. Right now localhost is considered protocol.

Validate whether url timestamping is needed for most browsers

On my brief testing, even latest Chromium and Firefox (on Ubuntu) needed timestamping to prevent unneccessary looping due to browser caching when xhr-polling. It was visible only when debugmode was on, firebug etc showed only successful requests as usual, but there were tens and even hundreds of "shadow responses" flowing in the debug log for each socket.send.

IPV6

i cannot connect between ipv6 addresses using engine.io client and engine.io
is use the ipv6 in [] backets and a port (9999 in the example)

and the transport.uri() also returns the correct uri:
ws://[aaaa:aaaa:aaaa:aaaa:aaaa:aaaa:aaaa:aaaa]:9999/engine.io/default/?uid=79968139529235726730246097&transport=websocket

i also tried updating the parseUri in utils.js according to this post and the parsing seems to work:

// socketio/socket.io-client#260
var re = /^(?:(?![^:@]+:[^:@\/]@)([^:\/?#.]+):)?(?://)?((?:(([^:@])(?::([^:@]))?)?@)?([[^\/?#]]|[^[][^:\/?#])(?::(\d))?)(((/(?:^?#)/?)?([^?#\/]))(?:?([^#]))?(?:#(.))?)/;

still, no connect is happening :(

consider making websocket transport consistent to others

Needs to measure what's the fastest -- 10xsend('A'), or 1xsend('AAAAAAAAAA').
And what is more reliable, at least virtually, a priori.

That's how I monkey patch the client, so far:

eio.transports.websocket.prototype.onData = function (data) {
  data = eio.parser.decodePayload(data)
  for (var i = 0, l = data.length; i < l; i++) {
    this.onPacket(data[i])
  }
};
eio.transports.websocket.prototype.write = function (packets) {
  this.socket.send(eio.parser.encodePayload(packets));
};

engine.io.js and strict mode?

Constructions like global = this result in effect in global = {}, not global = window for modern browsers (?). At least for Google Chrome 16.0.912.63 on 32-bit Linux.
This results in wrong feature detection and breaks the logic.

Evaluate whether browser sleep needs to be taken into account

In some places, such as pingTimeout, long setTimeouts are used (default 60 seconds for long polling). When the browser sleeps, such as when Android browser is backgrounded or screensaver kicks, the javascript execution is paused, but also the timers will be paused. When the browser execution continues again after sleep, the timers continue as if nothing happened, so that 60 seconds can be much longer. One should evaluate whether this should be detected, or if server timeouts such as pingInterval (default 25 secs) etc will take care of any issues. See (http://googlecode.blogspot.fi/2009/07/gmail-for-mobile-html5-series-using.html) for example -- the code examples have errors, but you get the point.

Also a related issue to be evaluated is browser suspends and wakeups on machine suspend/sleep, as I remember that with some libraries on long polling one can get errors from the network stack during suspend/wakeup, as the different layers can be started on different order. These things can be annoying. Do these things affect engine.io, have you seen any issues?

Document a preferred way to reconnect

To retain config and listeners, is it ok to reconnect by setting socket.id = null and then socket.open()? Otherwise the id will be sent with the request as query.sid, and it might be missing from the this.clients in Server.prototype.verify (and response 500 results, might be more appropriate with 404 or 410).

JSONP broken

JSONP Polling is not working at its current state. This apparently is because of several reasons, one of them being the assignment of a value attribute to a textarea.

XMLHttprequest imposes a hard limit on the maximum number of connections per host

I was writing some tests against remote hosts rather than localhost, and realized that there is a hard cap of 5 after which messages will no longer be received and sent correctly when using engine.io-client from Node.

The cap exists because of http://nodejs.org/api/http.html#http_http_request_options_callback where the default agents agent.maxSockets is 5.

Since all transports start as http connections, this cap applies to connections that are made simultaneously during a short time even if they use the websockets protocol later on.

The easy way to replicate this is to write a engine.io server that echos back to all connected clients.

Once you have about 3-4 client connections, messages are no longer echoed back to all of the connected clients - only a subset of clients will receive messages back. The rest of the connections do not work correctly.

There is a code path in Node core that removes http connections that have been upgraded to websockets from the pool, but since the initial handshake is still done by xmlhttprequest, doing multiple connections quickly (as in, in a test case that uses multiple engine.io instances to test server internal logic), the limitation still applies.

The fix is simple: https://github.com/driverdan/node-XMLHttpRequest/blob/master/lib/XMLHttpRequest.js#L358

add { agent: false } to disable the connection limit per host.

I'm filing this issue with XMLHttpRequest as well. Hopefully, this issue can be resolved. Once the agent connection limitation has been removed, engine.io-client will need to bump up the version of xmlhttprequest to resolve the issue.

IE9 cache issues

Hi,
Using latest (b5aba68) engine.io and associated (78f2471) client,
i get a failure with IE9 :

engine-client:socket creating transport "polling" +0ms 
engine-client:socket socket receive: type "open", data "{"sid":"3653182132859437","upgrades":["websocket"],"pingTimeout":60000}" +98ms 
engine-client:socket socket open +2ms 
engine-client:socket starting upgrade probes +2ms 
engine-client:socket probing transport "websocket" +1ms 
engine-client:socket creating transport "websocket" +1ms 
engine-client:socket socket receive: type "ping", data "undefined" +24s 
engine-client:socket flushing 1 packets in socket +0ms 
engine-client:socket socket close with reason: "ping timeout" +1.0m 
engine-client:socket socket closed prematurely - aborting probe +0ms 
SCRIPT5007: Unable to get value of the property 'close': object is null or undefined 
engine.io.js, line 1184 character 3

However, if i set cache settings to "every time i visit the web page" :

engine-client:socket creating transport "polling" +0ms 
engine-client:socket socket receive: type "open", data "{"sid":"1990083178490188","upgrades":["websocket"],"pingTimeout":60000}" +40ms 
engine-client:socket socket open +0ms 
engine-client:socket starting upgrade probes +0ms 
engine-client:socket probing transport "websocket" +1ms 
engine-client:socket creating transport "websocket" +0ms 
engine-client:socket socket receive: type "ping", data "undefined" +24s 
engine-client:socket flushing 1 packets in socket +0ms
engine-client:socket socket receive: type "ping", data "undefined" +24s 
engine-client:socket flushing 1 packets in socket +0ms

The second ping is eaten by IE ?!?

JSONPPolling.doWrite() perhaps funny

The logic in JSONPPolling.doWrite is clever. But the flow as now may be a bit funny as I understand it. On first doWrite, the form is created, its result target is set to a specific name, and it is appended to DOM for the rest of the session. Then an iframe of that name is created and appended to DOM for the request. Then the form is submitted, and the onload handler is set on the iframe to be triggered as the server responds with 'ok' which will be loaded to the target iframe.

But now in the onload handler, you callback the success but also remove the old one and create a new one? This is then removed and created anew on next doWrite. But perhaps this is intentional, preventing memory leaks or late triggers to nonexisting iframe? Ok if so. :)

And the synchorization of script tag and a form submit is quite hazy to me, hopefully there are no weird conditions there (I know this is the least common denominator transport, but still wondering). Good work in any case!

Different transports should be tuned for connection loss

Some experiments:

  1. XHR-polling, pull the cord: ping timeout in 60 secs. The good thing is that socket.send will error and disconnect immediately, so disconnect is easy to see when the user takes an action, or with a quick ping after a browser wakeup. Reconnecting seems easy, as the socket.open errored quickly when the network was down, so it could be repeated until success. (Haven't tried with proper network reachability issues but browser timeouts are usually reasonable.)
  2. JSONP, pull the cord: ping timeout in 60 secs. Unfortunately there are no errors coming from this transport. One will have to use custom RPC timeouts to detect that the connection is down. Also reconnecting is pain, as the socket.open does not give errors and hasn't got any timeouts, so it has to be opened with serial timeouts, clearing the last etc. Seems very easy to get stuck.
  3. WS, pull the cord: ping timeout in 60 secs. Surprisingly also here the transport is very quiet, and even socket.send seems to succeed (no errors, proper readystate, websocket.bufferedAmount stays at zero). I suspect that this 60 secs timeout will bite many, as things will seem unresponsive until timeout, disconnect and reconnect. WS transport is so lightweight and quick to establish, that quite quick heartbeats can be used, and a custom RPC call with a short timeout can be sent after browser wakeup etc. 60 secs ping timeout for websocket transport seems very bad, as reconnecting is so easy.

These are mostly application-level observations, but perhaps some transports could be tuned to ease the pain (I was very surprised by xhr vs. websockets)

Ping timers continue to live on after socket has been closed

The timers set in ping() and onHeartBeat() continue to live on, even if the socket is closed. I think these are causing my unit tests (running engine.io-client inside node) to never complete.

Should onClose clean these up?

clearTimeout(self.pingIntervalTimer);
clearTimeout(this.pingTimeoutTimer);

race condition when polling and upgrading

if there is an ongoing polling request and the client is not receiving any data, the upgrade blocks until the client gets a response on the poll, usually a ping packet. this makes the usage of websockets difficult, if the server is not continously sending messages.

this behavior can be observed more often if connecting to a remote server; it almost never happens if connecting via localhost in my tests.

tracebacks:

first part:

debug  : polling
debug  : xhr poll
debug  : sending xhr with url http://.../engine.io?uid=944483157247398450060002506&transport=polling&sid=7954197634546385 | data null
debug  : probe transport "websocket" opened - pinging
debug  : probe transport "websocket" pong - upgrading
debug  : pausing current transport "polling"
debug  : we are currently polling - waiting to pause

(after 20 seconds)

debug  : polling got 1:2
debug  : socket receive: type "ping" | data "undefined"
debug  : pre-pause polling complete
debug  : paused
debug  : changing transport and sending upgrade packet
debug  : clearing existing transport

[spec] rename session id

Consider renaming session id to connection id to avoid confusion. This is something that a lot of socket.io users are currently struggling with, they assume that the id is retrained across multiple connections while this is only used to identify the current connection.

Introduce `EIO` qs

EIO={protocol version}

should be sent along in every request's query string.

This goes with a SPEC.md change, but no protocol revision bump since it's not necessarily breaking.

node2node connection is down in first minutes

When i connect two nodes in first minute i have error message on client
and in next minute i have closed connection from client side.
This time is not depend on messages size and send frequlity

code:

  1. server side
var engine = require('engine')
  , server = engine.listen(80)

var counter = 0;
function getTimeMeasurementJavaScript(name, func){
      timeStart=new Date();
      func();
      totalTime = (new Date - timeStart);
      console.log(timeStart + " > " + name + ":" + totalTime + "msec" + " " + counter++);
}

server.on('connection', function (socket) {

  var execf = function(){
      getTimeMeasurementJavaScript("test",function(){
      socket.send("fff");
    })
  }

  setTimeout(execf,10)
  socket.on('message', function (data) {
        setTimeout(execf,100)
  })

  socket.on('close', function (data) {
        console.log ("connection closed")
  })  

  socket.on('error', function (data) {
        console.log ("error")
  })
});
  1. client side
var eio = require('engine.io-client')

var socket = new eio.Socket({ host: 'localhost', port: 80 });

socket.on('open', function () {
    console.log("open client connection")

  socket.on('message', function (myJSONText) {
        time=new Date();  
        console.log(" " + time + "  message=" + myJSONText)
        socket.send("ok")
    });

    socket.on('close', function () {
        console.log("connection is closed")
    });

    socket.on('error', function (data) {
        console.log ("error")
    })
});

and a question:
how i can trace connection info ?

engine.io.js generated file has invalid require paths

So the engine.io.js file that is generated with the new Makefile build contains invalid require paths.

So it has:
eio = require('engine.io-client');

But it's registered with:
require.register("lib//engine.io-client.js"

Which when included in the browser causes an error:
failed to require "engine.io-client"

It also appears as if it's maybe getting confused with the transports subdirectory as well?

xdomain requests are used unneccessarily, omitting cookies

I upgraded to 0.4.x and wondered quite a while why cookies were not transferred for same domain requests (on default port 80, omitting port from the url). The culprit was that eio used xdomain requests for the same domain, despite the good fixes earlier. I will look into this. On the other hand, decreasing the header size by omitting cookies could be feature too, but xdomain doesn't work on all browsers.

remove browserbuild dependency

I don't think it is used in the project anymore.

Also, update debug to 0.7.0 would be nice for those using bundling tools as 0.7.0 has the browserify field :)

Remember last actively working transport.

Back in the days of Socket.IO 0.6 we used a cookie to remember the current transport, so that we could re-use that information and skip some of the downgrading steps. It was later removed because it was not working.. But it was just poorly implemented as it deleted the complete list of available transports instead of re-ordering it and adding the last know transport on top.

We could be implementing the same in engine.io where the last known working (received and sends messages without issues) is remembered and use as the next transport to upgrade to after the initial connection has been established.

location.port can be an empty string and cause fallback to jsonp

There are a couple of places where global.location.port != opts.port is compared. As opts.port is defaulted to 80, but location.port can be an empty string (in Nokia N8, for example in my brief testing), this will cause the crossdomain flag to be set. And as xhr cors won't work on that phone, it will unneccessarily fall to jsonp transport. Xhr transport works otherwise in that phone, for same origin. So comparisons should be made only if (global.location.port). But I haven't tested https.

Corrupt repo

On cloning engine.io-client, doing git submodule init will result in No submodule mapping found in .gitmodules for path 'support/web-socket-js'

Is the module still being used, as I do not see an .gitmodules?

Socket#close error

OSX 10.7.5, Chrome 23.0.1271.101

engine.io.js:2358

 function initIframe () {
    if (self.iframe) {
      self.form.removeChild(self.iframe);
Uncaught Error: NOT_FOUND_ERR: DOM Exception 8
    }

app.js:

var express = require('express')
  , app = express().use(express.static(__dirname + '/public'))
  , http = require('http').createServer(app).listen(1337)
  , server = require('engine.io').attach(http, { transports: ['polling'] })
  ;

server.on('connection', function(socket) {
  console.log('connection');
  socket.on('message', function(message) {
    console.log('message: ' + message);
    socket.send('message: ' + message);
  });
});

public/index.html:

<!doctype html>
<html>
<head>
  <meta charset="utf-8">
  <title>Socket#close error</title>
</head>
<body>
  <script src="engine.io.js"></script>
  <script>
    var socket = new eio.Socket('ws://localhost:1337');
    socket.on('open', function() {
      console.log('open');
      socket.send('test');
    });
    socket.on('message', function(data) {
      console.log(data);
      socket.close();
    });
  </script>
</body>
</html>

edit: this only happens when i specify the polling transport, and only if i close the connection after receiving a message; closing in the open callback does not produce the error

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.