Socket.io: 이벤트에 대한 와일드카드 지원 추가

동의했다.

이벤트이미터2

+1
이렇게 하면 필터를 만들 수 있고 모든 이벤트에 대해 그렇지 않은 항목을 만들 수 있습니다.

• 또 다른 의존성
• 클라이언트 측에서 반영 되어야 합니다 (코드?)
• 특정 이벤트 전에 catchall을 호출해야 합니까? 또는 정의 순서대로? 설명 필요
• 동기화 동작만 -- 이벤트에 대한 사용자 정의 _async_ 필터를 도입하는 것이 좋지 않을까요?

+1

동기화 동작만 -- 이벤트에 대한 사용자 정의 비동기 필터를 도입하는 것이 더 낫지 않을까요?
@dvv

나는 이 아이디어에 꽤 관심이 있다.

일부 EE2 선택은 내가 이상적이라고 생각하는 것이 아니지만 "*"만 지원되는 경우에도 이에 대한 일반적인 아이디어를 +1합니다.

진정한 의미의 포괄: manager.on("event", function(client, event, data) {} -- 또한 ​​클로저 수를 줄일 수 있습니다.

catchall 리스너를 추가하는 것에 대한 저항은 기억나지 않습니다. 내가 기억하는 유일한 논쟁은 "*"를 사용하는지 아니면 .addGlobalListener()와 같은 다른 메서드 이름을 사용하는지 여부였습니다.

+1
나 역시 모든 이벤트를 가로채고 특정 핸들러가 이벤트를 처리하도록 하는 방법이 필요할 것입니다. 대부분 로깅 목적으로 필요합니다. Socket.io 로거는 현재 매우 독선적인 방식으로 콘솔에만 기록합니다.
dvv -s 접근 방식은 정말 마음에 듭니다.
사실 dvv에서 설명한 대로 이벤트를 특정 핸들러에 전달하고 모든 이벤트를 가져오는 것이 좋습니다.

이 문제를 움직여주세요 :)
이 기능이 구현되는 것을 보고 싶습니다.

음, 좋아, 방금 내 포크의 분기에 EE2를 추가했습니다. https://github.com/einaros/socket.io/commit/2107ff00f3ddf2d781d3e3c3b7dfb1fc990f7ec5

브랜치는 https://github.com/einaros/socket.io/commits/ee2에 있습니다.

생각은 가장 환영합니다.

EE2가 이상한 메서드 이름을 제거하고 .on('*') 추가하면

나는 EE2에서 -1이야

코드에 더 많은 부풀림을 추가하므로 클라이언트 측에서도 이를 지원해야 합니다. 이는 11.8KB 라이브러리를 추가로 배송해야 함을 의미합니다(약 3.5kb 축소). 그러나 다가오는 모바일 시장과 함께 가능한 한 많은 바이트를 절약하고 싶습니다.

이것이 단지 와일드카드/캐치 모든 리스너를 갖는 것에 관한 것이라면.. 그런 다음 all 리스너에 대한 추가 호출을 한 번만 수행하는 기존 방출 함수를 재정의하여 수행해야 합니다. 이것은 3 - 5 LOC 변경과 같습니다(주석 제외 ;)). 그리고 성능에 영향을 미치므로 기본 설정 잠금 뒤에 숨겨야 합니다. EventEmitting은 핫 코드 경로이며 항상 가능한 한 최적이고 빨라야 합니다. 와일드카드를 추가하면 성능이 저하됩니다.

catch-all은 확실히 더 중요한 부분입니다. 필요한 경우 그 후에 이벤트를 켤 수 있을 만큼 쉽습니다.

와일드 카드 또는 EE2에 대해서는 신경 쓰지 않지만 모든 이벤트를 가로채는 방법은 필수입니다.

EE2 ...가 .on('*')을 추가하면 +1

TJ 미친 형...

server.on('foo.*', function(value1, value2) {
  console.log(this.event, value1, value2);
});

그것은 EE2의 README에서 가져온 것입니다. 당연히 "후." 선택 사항입니다.

EE2가 이상한 메소드 이름을 제거하면

나는 동의한다.

@pyrotechnick the EE2 .on('*') 는 포괄적인 iirc가 아닙니다.

* 는 모든 이벤트를 맹목적으로 포착한다는 점에서 catch-all이 아니지만 * 패턴이 모든 채널과 일치하므로 모든 이벤트를 효과적으로 포착합니다.

비효율적입니다. 그러나 예상대로 작동합니다.

내가 틀렸어. 네가 옳아...

{EventEmitter2} = require 'eventemitter2'

emitter = new EventEmitter2 wildcard: on

emitter.on '*', ->
  console.log <strong i="6">@event</strong>, arguments...

emitter.emit 'foo'
emitter.emit 'foo.bar'

isabel:hydrogen pyrotechnick$ coffee test.coffee 
foo

나는 와일드 카드와 관련하여 거의 이 동작을 선호합니다.

이 모든 와일드카드/"네임스페이스" 이벤트에 대해 생각할 때 그것은 일종의 나를 슬프게 만듭니다. JavaScript는 패턴을 일치시키는 환상적인 방법을 이미 가지고 있습니다. 패턴은 //에 있거나 RegExp 됩니다. 너무 느린가요?

이것의 중요성을 다시 +1할 수 있습니까? 다음 릴리스에서 이것을 보고 싶습니다.

누군가 여기에 솔루션을 게시했습니다. http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

아직 이벤트에 연결할 수 없기 때문에 작동하지 않습니다. 내 응용 프로그램에서 서버는 클라이언트의 방 이름을 모릅니다. 그래서 저는 모든 방의 모든 메시지에 응답할 수 있고 이상적으로는 메시지가 전송된 방의 이름을 찾을 수 있기를 원합니다.

이벤트에 대한 정규식 지원을 추가합니다. 이런 식으로 동사와 명사의 범위를 잡을 수 있습니다.

+1

+1

+1

+1

+1

나는 모든 것을 처리하는 슈퍼 글로벌 방법을 좋아할 것입니다.

io.set('global_listener', function(네임스페이스, 이벤트, 인수, 방출){
// 네임스페이스 이벤트 및 인수를 기반으로 작업 수행
// 해당 네임스페이스 및 해당 이벤트와 연결된 이벤트 리스너를 호출하기 위해 emit()을 호출할 수 있거나 호출하지 않습니다.
});

io.set('global_authorization', function(네임스페이스, 핸드셰이크 데이터, 콜백){
// 네임스페이스 및 handshakeData 기반 연결 수락 여부
});

catch-all을 지원하는 이미터가 필요했습니다. 라. socket.on("*") , 클라이언트에서 작업했으며 여전히 가볍습니다. 그래서 UI Kit에서 @visionmedia 의 이미터를 가져 https://github.com/HenrikJoreteg/wildemitter

@HenrikJoreteg
https://github.com/component/emitter에 기본적으로 '*'를 추가할 수 있습니다
또한 이 이미터는 다음 socket.io에 전원을 공급할 것입니다. off removeListener 바로 가기가 포함되어 있어 좋습니다. :D

오, 굉장하다!

+1

++

+1

+1

+1

+1

+=1

+1

+1

+1

+1

아무도 이것에 대해 아직 일하지 않았습니까? 어떤 종류의 흔적?

우리가 필요로 하는 목적에 충분히 잘 작동하는 _일종의_ 솔루션이 있지만 완전한 와일드카드 솔루션은 아닙니다... '*'의 구현에 가깝습니다.

https://github.com/Attorney-Fee/socket.io

+1

+1

+1

+1

+1

+1

의미있는 기여가 없는 댓글을 남기긴 싫지만 2년 전부터 요청을 받았고 이미 건설적인 내용은 모두 언급했습니다. 그래서...

+1

이것은 사용자 영역에 추가하는 것이 상당히 쉬울 것입니다. 핵심 코드베이스에 추가할 필요가 없습니다. 너무 많은 원숭이 패치 없이 이벤트 이미터 기능을 쉽게 확장할 수 있도록 후크를 도울 수 있다면 기꺼이 돕겠습니다.

이것은 사용자 영역에서 어떻게 구현됩니까? 내가 본 모든 솔루션에는 코드베이스 분기가 포함되며 일부 사람들은 다른 라이브러리에 모두 연결했습니다.

제 경우에는 단순하고 단순한 "하나의 함수에서 모든 것을 절대적으로 잡아라"만 필요하지만 RegEx 지원은 (소스를 너무 자세히 보지 않은 사람에게) 너무 어렵게 보이지 않고 확실히 믿을 수 없을 정도로 유용할 것입니다. . 저는 Express.JS 경로에서 항상 정규식을 사용합니다. socket.io에서 동일한 작업을 수행할 수 있으면 좋을 것입니다.

전송 계층/프로토콜은 변경되지 않은 상태로 유지됩니다. 단순히 지도 조회가 아니라 보다 포괄적인(정규 표현식 기반) 검색을 수행하려면 양쪽 끝에서 '방출'을 재정의하면 됩니다.

빠른 구현 제안:

• 이벤트 이름에 '*'가 있는 경우 정규식에 대한 특수 데이터 구조를 유지하려면 on 재정의
• emit 를 재정의하여 먼저 빠른 경우(일반 맵 조회)를 수행한 다음 '*' 리스너를 살펴보고 일치하는지 확인합니다.

분명히 이것은 포크가 필요하지 않습니다. 후크가 의미하는 바는 원숭이 패치가 필요하지 않은 솔루션을 잠재적으로 찾을 수 있다는 것입니다. 그러나 이 두 가지가 매우 간단한 방법이라는 점을 고려하면 큰 문제라고 생각하지 않습니다.

그냥 궁금해서 userland에서 socket.Manager.prototype.onClientMessage를 재정의할 수 없었나요?

나는 그렇게했고 노드에서 socket.io 모듈을 변경하지 않고 잘 작동했습니다. 그다지 예쁘지 않고 부서지기 쉽지만 적어도 포크는 피해야 합니다.

https://gist.github.com/lmjabreu/5714985

socket.io가 필요하기 전에 단순히 process.EventEmitter = require('eventemitter2').EventEmitter2 어딘가에 추가할 수 없습니까? 이것은 나를 위해 작동하는 것 같습니다 ...

프로토타입을 여는 것은 확실히 사용자 영역 수정이 아닙니다. 나는 완전한 정규식 지원을 구현하고 싶지 않거나 단순한 socket.on('*')이 먼 길을 갈 것이라는 것을 이해합니다.

이 티켓은 이제 2년이 되었습니다.

분명히 유용한 기능이므로 이를 해결할 계획이 있습니까?

대답이 아니오라면 직접 포크하여 추가하고 싶습니다.
그러나 업스트림으로 병합될 가능성이 있는 경우에만 이 작업을 수행하는 것을 선호합니다.

어떤 개발자가 이것에 대답할 수 있습니까?

거의 모든 의견에 동의하지만 멋진 것은 논쟁의 여지가 적지만 포괄적인 것이 좋을 것입니다. 사용자가 직접 할 수 있지만 미리 정의된 절차가 더 깔끔합니다.

이것이 존재하지 않는다는 것이 유감입니다.

존재합니다. 이전에 누군가 게시한 링크를 참조하세요.
http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

나는 이것을 사용하고 있으며 훌륭하게 작동합니다 :)

+1

그렇게 간단한 것에 원숭이 패치를 하는 것은 나에게 나쁜 습관처럼 보이지만 큰 구현을 사용해서는 안 된다고 생각합니다. Backbone.Events 와 같은 간단한 것은 이 문제의 대부분의 개발자에게 충분할 것입니다. 제 생각에는. (백본은 "*"를 사용하지 않고 전역 이벤트에 대해 "모두"를 사용하지만 원래 호출된 이벤트 이름을 전달하는 것이 가장 좋은 방법입니다). (그러나 그것은 단지 제안일 뿐입니다) =)

개인적으로 RegExp 방식에 +1, "*" 와일드 카드와 비교할 때 더 많은 Javascript와 더 적은 콘솔을 느낍니다.

하지만 최근의 목소리들처럼 캐치올 기능이 더 적합한 것 같다.

이것이 실제로 socket.io 문제인지 확실하지 않습니다.

IMO를 비난하는 동결된 API.

:+1:

누군가 이 스레드를 읽고 0.9.x 및 1.0.0에서 와일드카드 이벤트를 사용하는 방법을 찾고 있는 경우: https://www.npmjs.org/package/socketio-wildcard

멋지다 @geoah !

@guille hehe, 내가 방금 우연히 발견한 것이 아닙니다. 열심히 해주셔서 감사합니다 btw ^_^

어젯밤 socket.io용 미들웨어를 준비했습니다.

https://www.npmjs.org/package/socket.io-events

+1
데이터가 항상 동일하게 처리될 때 새 리스너를 생성하는 오버헤드를 줄이는 것이 좋습니다.
@geoah 미들웨어에 감사드립니다. 내가 필요한 것을 정확히 했습니다!

미들웨어가 제대로 작동하면 socket.io가 그대로 유지되어야 합니다.

이것은 내가 개인적으로 socket.io 자체의 일부로 완벽하게 이해한다고 느끼는 것 중 하나입니다. 나는 "이곳에서 일이 진행되는 방식이 아니다"라는 말을 제외하고는 그것을 빼야 한다는 주장을 볼 수 없습니다. 이것은 결코 좋은 주장이 아닙니다.

주장은 우리가 노드 EventEmitter 처럼 작동하려고 하고 노드에는 이것이 없으므로 "socket.io-ism"이 될 것이라는 것입니다. Node에서 추가에 대한 광범위한 토론이 있었지만 통과하지 못했습니다.

@chevex 원래 제 느낌

그것들은 훨씬 더 나은 주장입니다. EventEmitter가 기본적으로 노드와 다르게 작동하는 것을 원하지 않을 것입니다. 그리고 @DanH42 또한 미들웨어로 이를 보강하는 것이 필요한 사람들에게 더 의미가 있다고 생각합니다. 제 발언을 철회합니다 :)

노드의 EventEmitter만 기본적으로 와일드카드를 지원하는 경우.

:+1:

이 문제를 놓친 것을 확인하고 이벤트 전달에 대한 새로운 문제를 시작했습니다.
https://github.com/Automattic/socket.io/issues/1715
여기에는 소스를 변경하지 않고 socket.io 1.0의 모든 이벤트를 처리하는 두 가지 방법이 포함됩니다.

디버깅을 위해 이것을 원합니다. 우리 프로젝트에 라이브러리를 추가하거나 수정할 권한이 없습니다. :흐느낌:

+1
때로는 전파되는 모든 이벤트를 알아야 합니다!

+1

• 1

나는 결국 hden의 socketio-wildcard 모듈을 사용하게 되었습니다. 미들웨어를 사용하여 가장 투명한 방법으로 보이며 저에게 아주 잘 작동합니다. 하지만 :+1: 이것을 핵심으로 하기 위해!

고마워 맷! 나는 늪에 빠졌지만 주말에 약간의 시간을 보낼 수 있기를 바랍니다.
개량

내 iPhone에서 보낸

2015년 1월 6일 오전 8시 30분에 Matt Fletcher [email protected] 은 다음과 같이 썼습니다.

나는 @NathanGRomano https://github.com/NathanGRomano 's를 사용하게 되었습니다.
socketio-events https://www.npmjs.com/package/socket.io-events 모듈; 그것
가장 투명한 방법(미들웨어 사용)으로 보이며 꽤 잘 작동합니다.
나를 위해 멋지게. 하지만 [이미지: :+1:] 이 내용을 핵심에 적용해 주셔서 감사합니다!

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Automattic/socket.io/issues/434#issuecomment -68864750.

+1

+1

++++++

+1은 디버깅에 유용합니다.

이 작업을 하는 사람의 문제라면 한 번 해보고 싶습니다. 나는 socket.io 코드베이스를 배우기 위해 몇 가지가 필요할 것이고 아마도 다른 그러한 구현을 살펴보는 데 시간을 할애할 것입니다. 정규식 패턴에 대해 어떻게 생각하십니까? 너무 느린? 물론, 병합 대상이 아닌 경우 시간을 낭비하지 않을 것입니다(구현이 거부되더라도 상관 없지만 관심이 없다면 귀찮게 할 이유가 없겠죠?). 유지 보수가 조언을 해 주시겠습니까?

나는 socket.io-events 라이브러리를 작성했습니다. 나는 일과 필요로 가득 차 있었다
다시 만지려면. 나는 그것으로 감사를 지원하고 싶습니다.

2015년 7월 25일 토요일에 John Manko [email protected] 은 다음과 같이 썼습니다.

이 일을 하고 있는 누군가의 문제라면, 나는 그것을 주고 싶다.
발사. 나는 socket.io 코드베이스를 배우기 위해 약간이 필요할 것이고 아마
다른 구현을 살펴보는 데 시간을 할애하십시오. 당신은 무엇입니까
정규식 패턴에 대한 생각? 너무 느린? 물론, 나는 내 것을 낭비하지 않을 것입니다.
병합을 고려할 대상이 아닌 경우 시간(나는
내 구현이 거부되더라도 관심이 없다면 왜
귀찮아, 그렇지?). 유지 보수가 조언을 해 주시겠습니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/socketio/socket.io/issues/434#issuecomment -124901706.

+1

+1 이 문제는 5년 동안 계속됩니다. 와일드카드 지원이 다시 추가되지 않은 이유는 무엇입니까?

+1

+1

+1

+1

+666

+1

얘들아, 진지하게. 모든 사람이 이 기능을 원합니다. 더하기만 합시다, 제발? 문제에 대한 실제 진행 상황이 있을 때 업데이트 이메일을 받고 싶습니다.

즉, 많은 사람들이 관심을 갖고 있다는 사실을 아는 것이 유용합니다.
이상적으로 GitHub에 투표 시스템이 있어야 한다고 생각합니까?

투표 시스템은 훌륭할 것이지만 조만간 일어날 것 같지 않습니다.

문제는 솔루션이 지금 여러 번 게시되었지만 모든 +1 댓글로 인해 보이지 않게 스크롤된다는 것입니다.

socketio-wildcard 모듈은 저에게 잘 작동하고 있습니다(아직 최신 노드로 업데이트하지 않았습니다).
누군가 이 라이브러리가 적합하지 않은 이유를 설명할 수 있다면 유용할 것입니다.

예, socketio-wildcard 는 완벽하게 작동하지만 여전히 너무 간단한 추가 종속성이므로 코어에 도입하고 이 전체 문제 스레드를 한 번에 끝내는 것이 좋습니다. 또한 사용하기에 가장 좋은 외부 모듈(종종 비슷한 이름)에 대한 혼란의 여지를 제거합니다. 또한 GitHub에 투표 시스템이 있다면, 우리가 그것에 대해 투표할 수 있는 방법만 있다면 좋을 것이라는 데 동의합니다...!

내가 멍청할 수도 있지만 IO 클라이언트 개체로 socketio-wildcard를 설정하는 방법에 대한 단서가 없습니다. 이것은 진지하게, _심각하게_ 핵심에 포함되어야 합니다. socket.io의 관리자가 하기를 원하지 않는다면 누군가 이 프로젝트를 포크해야 하고 우리는 모두 그곳으로 이동할 수 있습니다. 왜냐하면 이것은 말도 안되고 솔직히 지금 socket.io에 대한 신뢰가 없기 때문입니다.

관리자가 모든 제안을 수락할 필요는 없다는 것을 이해합니다. 하지만 이것은? 이것은 나를 완전히 당황하게합니다. 잘 했어.

@n2liquid 이것이 핵심이어야 하는지는 분명하지 않지만 토론은 환영합니다. 예를 들어, 토론이 있었을 때에도 다른 Node 이벤트 이미터는 이러한 방식으로 작동하지 않습니다.

@rauchg

이것이 핵심이어야 하는지는 분명하지 않지만 토론은 환영합니다.

그러면 이에 대해 토론할 수 있을까요?

이런 종류의 에미터가 노드 세계에서 반드시 일반적이지는 않지만 달성하려는 목표에 따라 다르다는 점을 이해할 수 있습니다....
규칙을 엄격히 준수하거나 정말 유용한 라이브러리를 제공하려는 아이디어입니까?

socket.io의 많은 사용자들이 이 기능이 핵심에 있지 않은 상태에서 정말 비틀거리고 있는 것이 분명해 보이며 사용자가 그렇게 되어야 한다고 예상하는 것이 합리적으로 보입니다.

또는 달리 말하면 socket.io에서 이 기능을 제공하지 않는 인수는 무엇입니까?
구현이 '교과서 올바름'이 아니더라도 사람들이 다양한 라이브러리와 메서드에 의존하는 대신 socket.io에서 이러한 '캐치' 핸들러를 구현하는 표준 방법이 될 것입니다.
사람들을 타사 라이브러리 또는 해결 방법으로 안내하면 사물이 단편화되고 socket.io를 사용하는 코드베이스를 유지하려는 시도가 훨씬 더 취약해집니다.

나는 오히려 catchall 패킷을 처리하는 공식적인 방법이 있고 나중에 변경해야 하는 경우 사용자가 황야를 통과하는 자신의 경로를 찾도록 두는 것보다 최소한 권장되는 마이그레이션 절차가 있을 수 있습니다.

@rauchg 이것을 구현하는 멋진 방법은 소켓의 모든 이벤트를 포착하는 socket.use(function(data,next){..}) 함수를 사용하고 catchall에서 후속 catchall 또는 기본 이벤트 처리기로 제어를 전달하는 next() 함수를 전달하는 것이라고 생각합니다. .

이것이 내가 현재 사용하는 방법입니다. 왜냐하면 분당 들어오는 이벤트의 양을 제한하는 방법이 필요했기 때문입니다. 이는 일반적인 사용 사례라고 생각합니다. 제 2센트를 읽어주셔서 감사합니다.

@Michael77 의 솔루션이 가장 @Michael77 의 메시지 조절 구현 및 그 외에 누가 알

socket.io에 미들웨어/사용 기능이 있다는 것을 알고 있지만 클라이언트 라이브러리에서 사용할 수 없으며 동일한 용도로 사용되는지 확실하지 않습니다.

@carpii 항상 무언가를 지원하지 _않은_ 큰 이유가 있습니다. 복잡성을 추가하고 친숙함을 줄이는 것입니다. 이 기능은 둘 다 확인합니다.

나는 socket.use 아이디어를 아주 좋아하는데, 무엇보다도 클라이언트에서 와일드카드 확장을 쉽게 구현할 수 있습니다.

이 btw에 대한 피드백을 보내 주신 @carpii @Michael77 @n2liquid 에게 감사드립니다.

@rauchg ,

또한: https://github.com/hden/socketio-wildcard/issues/13

@n2liquid _all_ 피드백을 환영합니다. 감사합니다(또한 socket.io-wildcard 에 대한 빠른 수정을 위해 @hden 에게 감사합니다).

scoketio-wildcard는 완벽하게 유효한 솔루션인 것 같습니다. 또한 내 응용 프로그램의 나머지 부분에 소켓을 직접 노출하는 대신 소켓 수신기를 래핑하고 래퍼를 통해 이벤트를 전파할 수 있도록 콜백에서 이벤트 이름을 얻고 싶었습니다. 와일드카드로 이 작업을 수행하려면 Event Emitter 2가 필요하다는 것이 제 이해입니다. 소켓을 직접 노출하는 것이 더 나은 어리석은 일입니까? 래퍼에서 'newListener' 수신을 기반으로 하는 것(그러나 소켓 이벤트에서 트리거하는 방법을 모르고 래퍼에서 새 이벤트를 등록하는 호출 함수를 기반으로 소켓 이벤트를 등록하는 방법만)? 콜백 내에서 이벤트 이름에 액세스하는 데 관심이 있는 다른 사람이 있습니까?

@akotlar 이벤트 이름은 scoketio-wildcard를 사용하는 경우 콜백에서 사용할 수 있습니다.

아, 고마워! socket.io-wildcard readme에서 이것을 지정하는 것이 유용할 수 있습니다.

어떻게 지내요?
클라이언트와 서버 모두 on("*", function () { 에 +1

끝까지 +1

@alexey-sh @emin93 https://github.com/hden/socketio-wildcard 에서 문서를 친절하게 읽으 신다면 예, 클라이언트와 서버 모두에서 그렇게 할 수 있습니다.

@hden 감사합니다 그리고 예, 나는 그것을 보았고 이미 그것을 사용하고 있습니다. 그러나 그것은 추가 종속성이며 Socket.IO 코어에 직접 통합하는 것에 대해 아무 말도 하지 않습니다. 그렇기 때문에 저로부터 +1을 얻습니다.

모든 이벤트에 대해 하나의 이벤트 이름을 사용하여 앱 로직에서 처리할 수 있습니다.

socket.emit('public-event', {'type': 'login', ...});
socket.emit('public-event', {'type': 'logout', ...});

문제가 종료된 경우에도 +1입니다.

+💯 쾅!

+1!!!!

socket.use 사용하세요.

socket.use()를 사용하여 engine.io의 PING/PONG 메커니즘에 연결하는 방법이 있습니까?

많은 사용자가 연결이 끊기는 문제가 있으며 서버에 대한 광범위한 로그온에도 불구하고 Ping 시간 초과로 인해 연결이 끊겼다고만 표시됩니다.

PING/PONG 패킷을 기록하고 싶지만 socket.use()는 높은 수준의 사용자 이벤트 메시지에만 연결할 수 있고 engine.io의 기본 프로토콜은 연결할 수 없는 것 같습니다.

+1

+1

2011년부터 +1? 그들은 그것을하지 않습니다. :(

다시, 그 문제에 대해 socket.use 가 추가되었습니다. https://socket.io/docs/server-api/#socket -use-fn

@darrachequesne 서버 측의 메소드가 이 요청(클라이언트용)에 어떻게 도움이 되는지

이것에 대해 더 이상? socket.use 는 서버 전용인데 왜 이 티켓이 닫혀 있습니까?

socket.use 이해할 수 없습니다. 교체 방법

// Server
io.in('room1').emit('backend', data_out);
io.in('room1').emit('frontend', data_out);

와 같은

// Server
io.in('room1').emit('*end', data_out);  // not working code - proper regex would be nice

또는

// Client
socket.on('*end', function(data){  // not working code - proper regex would be nice

모든 가능성을 나열하는 작은 해결 방법을 찾았습니다.

// Client
var lala = function(data){ 
    // example
}
socket.on('backend', lala);
socket.on('frontend', lala);