Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 03 05:49
    pentestusa commented #524
  • Oct 30 05:55
    pentestusa commented #524
  • Sep 01 10:47
    JojoStacy commented #429
  • Aug 14 17:36
    SeedyROM closed #535
  • Aug 10 16:14
    SeedyROM commented #535
  • Aug 07 21:02
    SeedyROM commented #535
  • Aug 07 13:31
    jondubois commented #535
  • Aug 07 13:30
    jondubois commented #535
  • Aug 07 13:30
    jondubois commented #535
  • Aug 07 13:29
    jondubois commented #535
  • Aug 06 18:16
    SeedyROM opened #535
  • Jul 20 13:43

    dependabot[bot] on npm_and_yarn

    (compare)

  • Jul 20 13:43
    dependabot[bot] closed #533
  • Jul 20 13:42
    dependabot[bot] edited #533
  • Jul 20 13:42
    dependabot[bot] commented #533
  • Jul 20 13:42
    dependabot[bot] edited #533
  • Jul 20 13:42

    jondubois on master

    Bump package-lock (compare)

  • Jul 20 13:29

    jondubois on old

    Updated dependencies Merge pull request #532 from di… (compare)

  • Jul 20 13:29
    jondubois closed #532
  • Jul 19 14:07
    arya-man opened #534
Kevin Boon
@inQonsole
@ghibble you mean listen to the connection and disconnection event on the server side ?
AllOverIO
@ghibble
@inQonsole on the client side. https://github.com/SocketCluster/socketcluster-client#subscribe-to-a-channel but I would like to trigger code to pull an update on re-connections (if the connection is lost or dropped). So on the client, upon [re]connection, execute x,y,z
Kevin Boon
@inQonsole
oke but you said, how to capture/trigger a callback on the server
oke so you are trying to listen on the client side gotcha
AllOverIO
@ghibble

And I might be thinking about this wrong..

(async () => {

// Subscribe to a channel.
let myChannel = socket.subscribe('myChannel');

await myChannel.listener('subscribe').once();
// myChannel.state is now 'subscribed'.

DO I PUT MY "NOW CONNECTED" CODE HERE ?
})();

But I was hoping on the client to add ...

socket.on("subscribe", function())
socket.on("connected",function())

Or something like this. I am not seeing if this is possible on the node socketcluster client ?

also...
socket.on("disconnected",function()...) so I can trigger some UI changes on my application :D
Kevin Boon
@inQonsole
mmmm looks a bit wrong,
(async () => {
        for await (let event of socket.listener('connect')) {
          // connect event
        }
      })();

      (async () => {
        for await (let event of socket.listener('disconnect')) {
          // disconnect event (after handshake)
        }
      })();

      (async () => {
        for await (let event of socket.listener('connectAbort')) {
          // connectAbort event
        }
      })();
AllOverIO
@ghibble
Let me try this ^^^ Thank you.
Kevin Boon
@inQonsole
@ghibble your welcome let me know if you run into anything else or have any other questions :)
AllOverIO
@ghibble
@inQonsole beautiful, works like a charm :D
Kevin Boon
@inQonsole
@ghibble No problem at all let me know you need anything else :)
Frank Lemanschik
@frank-dspeed
@inQonsole
would you integrate a new engine? and test it when i give you some?
i am working at present on actix for nodejs via neo bindings as .node module
but i would love to see it used in the wild if you like i would put you on the list i expect much better performance then uws
Kevin Boon
@inQonsole
@frank-dspeed sure thing, I can test it in one of our deployment servers.
Kevin Boon
@inQonsole
regarding that jon said that the performance increase for a uws vs ws in a normal socketcluster for chat is minimal, is very true, the bottleneck would be nodejs in this sense, where we use uws is in our online subsystem (online mutiplayer lobby, matchmaking, authentication system) it's solely binary, so it really depends on use cases and code optimization to get better performance out of your cluster. there is no magic wand that makes everything 200% better, unless your switching coding languages of course.
just to be clear, other wise ppl start saying Kevin said switching to uws makes performance better, but thats not what i said :P
Eric Guan
@guanzo
can i ask what game you're working on?
Paul
@wilensky

Okay. Quick test showed few things:

  1. I was able to send message to a channel from external UI
  2. This mesasge was mentioned by broker as ::ffff:10.200.1.112 published to xxxCHxxx
  3. No errors so far

Current points:

External clients are connecting to scc-workers by wss namely { secure: true }. All those workers are behind ELB and last s in wss is a ELB responsibility if I remember it right. Continuing investigation ...

Frank Lemanschik
@frank-dspeed
Switching coding language to Java + vertx for example using ES4X would improve performance a lot
while you could use javascript for your logic
entangledq
@entangledq
is there anyway to cancel sending of a message to others subscribing to a channel based on some condition? ie when a client sends "#publish" event. middleware thing wouldn't help i think as there's a need to receive stuff in "#publish" but cancel sendong to others subscribed to the same channel based on some conditions.
Paul
@wilensky
@entangledq the channel is a shared media and here everything that is sent to it will be received by all subscribed parties. We have a case when we want to ignore some of the messages for some clients. For this purpose each event of such kind has an uuid and user knows that he wants to ignore event with such id for a reason. It seems we cant prevent sending message to certain sockets of a channel after it was published to a channel.
entangledq
@entangledq
theres two solutions. one ignoring based on data exchanged over the channel eg metadata things n the other is a common channel between clients that non subscribe to; this way server can differentiate data based on channel n at the same time non of the clients have received junk data not used for any purposes. the goal of ma question is that y client must receive additional junk data
clients whether it be iOS android or web code complexity increases even though the business logic have stayed the same
beside that remember that some middlewares could put some conditions on received messages so maybe could ignore the message there but the problem is that the logic is scattered which smells buggy, is prone to error, n hard to extend, debug, n maintain
this pub/sub thing makes dealing with distributed websocket easier but lack some functionalities imo
Paul
@wilensky
It is also possible by dynamically reporting channels (multicast groups) to clients that need to receive that important message and client will auto-subscribe for such channel for 1-time message e.g.
Smth. like: "ya'll subscribe to this channel except you and you". This short message can be broadcasted on some common channel.
entangledq
@entangledq
another question. there's kubernetes cluster config files on the socketcluster repo. my q is that is there any real world example using socketcluster in k8s cluster reversed proxied by nginx or traefik
my current customer khas 3 million users n were running a private cloud for them
(no time to benchmark at the moment)
n default replicaset of the deployment is set to 1
specifically any problem with load balancing? no that its MAY not be related but curious to no others have thought about it
@wilensky about common channel ur talking about. currently using two uuid's one for server to user n one for client to clients. so server push metadata to clients of its choice using first one but it's not scalable
entangledq
@entangledq
for example, y would server intervene when clients want to report their status. only if the status is important n server must store status history
entangledq
@entangledq
(report their status to each other ie clients to other clients)
Paul
@wilensky
@entangledq agree ...
Yamuna99
@Yamuna99

@inQonsole

message: "Event response for "#publish" timed out"

stack: "Error↵    at new TimeoutError

I am getting above error while publishing a message from frontend side and I have set middleware at backend side
without middleware it's working fine

Paul
@wilensky

@inQonsole next question on the same topic.

SilentMiddlewareBlockedError: The publishIn AGAction was blocked by inbound middleware

Does this error occur when any of existing 1+ workers block this event on INBOUND :question:
Bec. here is the case when I have e.g. 5 workers and I'm blocking particular event on 4 out of 5, so only 1 single inbound allows this event to propagate. Probably not the best approach, but it seemed to me that message routed by broker to all presumably valid instances forward the decision on whether to block or not solely for this particular worker instance, but now it seems that if any of available instances blocks event on INBOUND it considered as failed :question:

Maybe I misunderstood the concept of action.block() on PUBLISH_IN

Paul
@wilensky

So after some unknown fix applied from devops side and my rambling around and adding missing stuff like error output, backoff strategies for hung connections etc. finally I got it working. I don't know what namely turned it to life, but it just started working at some point. Thanks for help guys! Its always easier when you just talk to other people.

Also I corrected middleware simply to .allow(), but gotta switch this to channel soon.

Kevin Boon
@inQonsole
@Yamuna99 Means your middleware is blocking the publish, make sure to set up your middleware correctly, you need either an action.block() or an action.allow() to either block the publish or to allow it depending on the rules you set, but right now it's doing neither so it's timing out because your blocking it from sending a response back.
@wilensky Yeah same thing paul, you can either block or allow the publish depending on your rules, so make sure you setup your rules correctly, i'm glad you got everything working now :)
Paul
@wilensky

@inQonsole but the question is still there ))

If we are running a cluster and one of the instance of scc-worker makes .block() to a message on PUBLISH_IN stage, does it mean that this message will be rejected on all other instances or it will be rejected only for that particular instance that made .block()on PUBLISH_IN :question:

Kevin Boon
@inQonsole
@wilensky only applies to that instance, so who ever, or whatever is connected to that worker, is where the middleware applies to.
Paul
@wilensky

Okay. Thanks. That makes sense. Will check once again later on this.

And ) happy oncoming weekend to all!

Kevin Boon
@inQonsole
scc-worker-1 and scc-worker-2 are unrelated to each other, they don't know that they exist, only the scc-state knows, the scc-state informs the scc-broker, hey if you recieve a message, you gotta send it to this instance as well because according to me it's exist. basically
No worries let me know if you run into anything else.
Eric Guan
@guanzo
question about SCC_CLIENT_POOL_SIZE. does this just create more connections to the same broker, for connection reliability?