node ipc
10.1.0
ein NodeJS-Modul für lokale und Remote-Interprozesskommunikation mit vollständiger Unterstützung für Linux, Mac und Windows. Es unterstützt außerdem alle Formen der Socket-Kommunikation von Low-Level-Unix- und Windows-Sockets bis hin zu UDP und sicheren TLS- und TCP-Sockets.
Eine großartige Lösung für komplexe neuronale Multiprozess-Netzwerke in Node.JS
npm install node-ipc
npm install node-ipc@^9.0.0
//es6
import ipc from 'node-ipc'
//commonjs
const ipc = require ( 'node-ipc' ) . default ;
NPM-Info: Siehe NPM-Trends und -Statistiken für Node-IPC
GitHub-Info:
Informationen zur Codeabdeckung:
Führen Sie npm run coverage aus, um eine lokale Version des Abdeckungsberichts auf „localhost:8080“ zu hosten. Dies ist das gleiche Format wie in Istanbul und NYC. Es sollte sehr vertraut sein.
Der Test wurde mit Vanilla-Test durchgeführt
vanilla-test lässt sich für eine native ESM-Abdeckung in c8 integrieren, ohne dass Sie Ihren Code transpilieren müssen. Zum Zeitpunkt des Verfassens dieses Artikels ist dies die einzige Möglichkeit, ESM nativ zu testen, und es ist erstaunlich!
Websites mit Paketdetails:
Dieses Werk ist über die MIT-Lizenz lizenziert.
Die neuesten Versionen von node-ipc funktionieren möglicherweise mit dem Flag --harmony. Offiziell unterstützen wir jedoch Knoten v4 und neuer mit es5 und es6
npm test führt die Jasmine-Tests mit Istanbul für Node-IPC aus und generiert einen Abdeckungsbericht im Spec-Ordner.
Möglicherweise möchten Sie Jasmin und Istanbul global mit sudo npm install -g jasmine istanbul installieren
| Typ | Stabilität | Definition |
|---|---|---|
| Unix-Socket oder Windows-Socket | Stabil | Ermöglicht eine blitzschnelle Kommunikation zwischen Linux, Mac und Windows und vermeidet die Netzwerkkarte, um Overhead und Latenz zu reduzieren. Beispiele für lokale Unix- und Windows-Sockets |
| TCP-Socket | Stabil | Bietet die zuverlässigste Kommunikation im gesamten Netzwerk. Kann auch für lokale IPCs verwendet werden, ist jedoch langsamer als die Unix-Socket-Implementierung Nr. 1, da TCP-Sockets über die Netzwerkkarte laufen, Unix-Sockets und Windows-Sockets hingegen nicht. Beispiele für lokale oder Remote-Netzwerk-TCP-Sockets |
| TLS-Socket | Stabil | Konfigurierbarer und sicherer Netzwerk-Socket über SSL. Entspricht https. TLS/SSL-Dokumentation |
| UDP-Sockets | Stabil | Bietet die schnellste Netzwerkkommunikation . UDP ist weniger zuverlässig, aber viel schneller als TCP. Es eignet sich am besten zum Streamen nicht kritischer Daten wie Ton-, Video- oder Multiplayer-Spieldaten, da es je nach Netzwerkkonnektivität und anderen Faktoren zu Paketverlusten kommen kann. UDP kann auch für lokale IPCs verwendet werden, ist jedoch langsamer als die Unix-Socket- oder Windows-Socket-Implementierung Nr. 1, da UDP-Sockets über die Netzwerkkarte laufen, Unix- und Windows-Sockets hingegen nicht. Beispiele für UDP-Sockets im lokalen oder Remote-Netzwerk |
| Betriebssystem | Unterstützte Sockets |
|---|---|
| Linux | Unix, Posix, TCP, TLS, UDP |
| Mac | Unix, Posix, TCP, TLS, UDP |
| Gewinnen | Windows, TCP, TLS, UDP |
ipc.config
Legen Sie diese Variablen im Bereich ipc.config fest, um Standardwerte zu überschreiben oder festzulegen.
{
appspace : 'app.' ,
socketRoot : '/tmp/' ,
id : os . hostname ( ) ,
networkHost : 'localhost' , //should resolve to 127.0.0.1 or ::1 see the table below related to this
networkPort : 8000 ,
readableAll : false ,
writableAll : false ,
encoding : 'utf8' ,
rawBuffer : false ,
delimiter : 'f' ,
sync : false ,
silent : false ,
logInColor : true ,
logDepth : 5 ,
logger : console . log ,
maxConnections : 100 ,
retry : 500 ,
maxRetries : false ,
stopRetrying : false ,
unlink : true ,
interfaces : {
localAddress : false ,
localPort : false ,
family : false ,
hints : false ,
lookup : false
}
}| Variable | Dokumentation |
|---|---|
| Appspace | Wird für den Unix-Socket-Namespace (Unix-Domain-Socket) verwendet. Wenn nicht speziell festgelegt, kombiniert der Unix-Domänen-Socket socketRoot, appspace und id, um den Unix-Socket-Pfad für die Erstellung oder Bindung zu bilden. Dies ist verfügbar, wenn auf Ihrem System viele Apps ausgeführt werden. Möglicherweise verfügen Sie über mehrere Sockets mit derselben ID. Wenn Sie jedoch den Appspace ändern, verfügen Sie weiterhin über App-spezifische eindeutige Sockets. |
| socketRoot | das Verzeichnis, in dem ein Unix-Socket erstellt oder daran gebunden werden soll |
| Ausweis | Die ID dieses Sockets oder Dienstes |
| networkHost | der lokale oder Remote-Host, auf dem TCP-, TLS- oder UDP-Sockets eine Verbindung herstellen sollen |
| NetzwerkPort | Der Standardport, über den TCP-, TLS- oder UDP-Sockets eine Verbindung herstellen sollen |
| lesbarAlle | Macht die Pipe für alle Benutzer einschließlich Windows-Diensten lesbar |
| beschreibbarAlle | Macht die Pipe für alle Benutzer, einschließlich Windows-Diensten, beschreibbar |
| Codierung | die Standardkodierung für Daten, die über Sockets gesendet werden. Wird meist verwendet, wenn rawBuffer auf true gesetzt ist. Gültige Werte sind: ascii utf8 utf16le ucs2 base64 hex . |
| rawBuffer | Wenn „true“, werden Daten als Buffer gesendet und empfangen, NICHT als Object als JSON. Dies eignet sich hervorragend für Binär- oder Hex-IPC und die Kommunikation mit anderen Prozessen in Sprachen wie C und C++ |
| Trennzeichen | das Trennzeichen am Ende jedes Datenpakets. |
| synchronisieren | synchrone Anfragen. Clients senden keine neuen Anfragen, bis der Server antwortet. |
| still | Der Standardwert „Protokollierung ein-/ausschalten“ ist „false“, was bedeutet, dass die Protokollierung aktiviert ist |
| logInColor | util.inspect-Farben für ipc.log ein-/ausschalten |
| logDepth | Legen Sie die Tiefe für util.inspect während ipc.log fest |
| Logger | die Funktion, die die Ausgabe von ipc.log empfängt; sollte ein einzelnes String-Argument annehmen |
| maxConnections | Dies ist die maximal zulässige Anzahl von Verbindungen zu einem Socket. Es wird derzeit nur auf Unix-Sockets gesetzt. Andere Socket-Typen verwenden die Systemstandards. |
| wiederholen | Dies ist die Zeit in Millisekunden, die ein Client wartet, bevor er versucht, die Verbindung zu einem Server wiederherzustellen, wenn die Verbindung unterbrochen wird. Dies wirkt sich nicht auf UDP-Sockets aus, da diese keine Client-Server-Beziehung wie Unix-Sockets und TCP-Sockets haben. |
| maxRetries | Wenn dieser Wert festgelegt ist, stellt er die maximale Anzahl von Wiederholungsversuchen nach jeder Trennung dar, bevor eine bestimmte Verbindung aufgegeben und vollständig beendet wird |
| stopRetrying | Der Standardwert ist „false“, was bedeutet, dass Clients im Wiederholungsintervall auf unbestimmte Zeit erneut versuchen, eine Verbindung zu Servern herzustellen. Wenn eine beliebige Zahl eingestellt ist, stoppt der Client den erneuten Versuch, wenn diese Zahl nach jeder Verbindungstrennung überschritten wird. Wenn es in Echtzeit auf „true“ gesetzt ist, wird der Versuch, eine Verbindung herzustellen, unabhängig von maxRetries sofort beendet. Wenn der Wert auf 0 gesetzt ist, versucht der Client NICHT , die Verbindung wiederherzustellen. |
| Verknüpfung aufheben | Der Standardwert ist „true“, was bedeutet, dass das Modul vor dem Start dafür sorgt, dass der IPC-Socket gelöscht wird. Wenn Sie node-ipc in einer Clusterumgebung verwenden, in der mehrere Listener auf demselben Socket vorhanden sind, müssen Sie dies auf false setzen und dann dafür sorgen, dass der Socket in Ihrem eigenen Code gelöscht wird. |
| Schnittstellen | Wird hauptsächlich verwendet, wenn angegeben wird, über welche Schnittstelle ein Client eine Verbindung herstellen soll. Weitere Informationen finden Sie in der Dokumentation zu socket.connect in der node.js-API |
Diese Methoden sind im IPC Scope verfügbar.
ipc.log(a,b,c,d,e...);
ipc.log akzeptiert eine beliebige Anzahl von Argumenten und wenn ipc.config.silent nicht festgelegt ist, werden sie alle mit einem einzigen Leerzeichen „ “ dazwischen verkettet und dann in der Konsole protokolliert. Dies ist schnell, da es jegliche Verkettung verhindert, wenn ipc.config.silent auf true gesetzt ist. Wenn Sie die Protokollierung beibehalten, sollte dies auf diese Weise nahezu keine Auswirkungen auf die Leistung haben.
Das Protokoll verwendet auch util.inspect. Sie können über ipc.config steuern, ob die Protokollierung in Farbe, Protokolltiefe und Ziel erfolgen soll
ipc . config . logInColor = true ; //default
ipc . config . logDepth = 5 ; //default
ipc . config . logger = console . log . bind ( console ) ; // default ipc.connectTo(id,path,callback);
Wird für die Verbindung als Client mit lokalen Unix-Sockets und Windows-Sockets verwendet. Dies ist der schnellste Weg für die Kommunikation von Prozessen auf demselben Computer, da die Netzwerkkarte umgangen wird, die sowohl TCP als auch UDP verwenden müssen.
| Variable | erforderlich | Definition |
|---|---|---|
| Ausweis | erforderlich | ist die String-ID des Sockets, mit dem eine Verbindung hergestellt wird. Der Socket mit dieser ID wird beim Erstellen zum ipc.of-Objekt hinzugefügt. |
| Weg | optional | ist der Pfad der Unix-Domänen-Socket-Datei. Wenn das System Windows ist, wird dieser automatisch in eine entsprechende Pipe mit denselben Informationen wie die Unix-Domänen-Socket-Datei konvertiert. Wenn nicht festgelegt, wird standardmäßig ipc.config.socketRoot + ipc.config.appspace + id verwendet |
| Rückruf | optional | Dies ist die Funktion, die ausgeführt werden soll, wenn der Socket erstellt wurde. |
Beispielargumente können weggelassen werden, solange sie noch in Ordnung sind.
ipc . connectTo ( 'world' ) ;oder nur eine ID und einen Rückruf verwenden
ipc . connectTo (
'world' ,
function ( ) {
ipc . of . world . on (
'hello' ,
function ( data ) {
ipc . log ( data . debug ) ;
//if data was a string, it would have the color set to the debug style applied to it
}
)
}
) ;oder den Pfad explizit festlegen
ipc . connectTo (
'world' ,
'myapp.world'
) ;oder den Pfad explizit mit Rückruf festlegen
ipc . connectTo (
'world' ,
'myapp.world' ,
function ( ) {
...
}
) ; ipc.connectToNet(id,host,port,callback)
Wird verwendet, um als Client über die Netzwerkkarte eine Verbindung zu einem TCP- oder TLS-Socket herzustellen. Dies kann lokal oder remote sein. Wenn lokal, wird empfohlen, stattdessen die Unix- und Windows-Socket-Implementierung von connectTo zu verwenden, da diese viel schneller ist, da die Netzwerkkarte vollständig umgangen wird.
Informationen zu TLS- und SSL-Sockets finden Sie in den TLS- und SSL-Dokumenten von node-ipc. Sie haben ein paar zusätzliche Anforderungen und Dinge, über die Sie Bescheid wissen sollten, und verfügen daher über ein eigenes Dokument.
| Variable | erforderlich | Definition |
|---|---|---|
| Ausweis | erforderlich | ist die String-ID des Sockets, mit dem eine Verbindung hergestellt wird. Bei TCP- und TLS-Sockets wird diese ID dem ipc.of Objekt hinzugefügt, wenn der Socket mit einem Verweis auf den Socket erstellt wird. |
| Gastgeber | optional | ist der Host, auf dem sich der TCP- oder TLS-Socket befindet. Wenn nicht angegeben, wird standardmäßig ipc.config.networkHost verwendet. |
| Hafen | optional | der Port, auf dem sich der TCP- oder TLS-Socket befindet. |
| Rückruf | optional | Dies ist die Funktion, die ausgeführt werden soll, wenn der Socket erstellt wurde. |
Beispielargumente können weggelassen werden, solange sie noch in Ordnung sind.
Während die Standardeinstellung lautet: (id,host,port,callback), funktionieren die folgenden Beispiele dennoch, da sie immer noch in der Reihenfolge (id,port,callback) oder (id,host,callback) oder (id,port) usw. sind .
ipc . connectToNet ( 'world' ) ;oder nur eine ID und einen Rückruf verwenden
ipc . connectToNet (
'world' ,
function ( ) {
...
}
) ;oder explizites Festlegen des Hosts und Pfads
ipc . connectToNet (
'world' ,
'myapp.com' , serve ( path , callback )
3435
) ;oder nur Port und Rückruf explizit festlegen
ipc . connectToNet (
'world' ,
3435 ,
function ( ) {
...
}
) ; ipc.disconnect(id)
Wird verwendet, um einen Client von einem Unix-, Windows-, TCP- oder TLS-Socket zu trennen. Der Socket und seine Referenz werden aus dem Speicher und dem ipc.of Bereich entfernt. Dies kann lokal oder remote sein. UDP-Clients unterhalten keine Verbindungen, daher gibt es keine Clients und diese Methode hat für sie keinen Wert.
| Variable | erforderlich | Definition |
|---|---|---|
| Ausweis | erforderlich | ist die String-ID des Sockets, von dem die Verbindung getrennt werden soll. |
Beispiele
ipc . disconnect ( 'world' ) ; ipc.serve(path,callback);
Wird zum Erstellen eines lokalen Unix-Socket-Servers oder Windows-Socket-Servers verwendet, an den sich Clients binden können. Der Server kann Ereignisse an bestimmte Client-Sockets emit oder Ereignisse an alle bekannten Client-Sockets broadcast .
| Variable | erforderlich | Definition |
|---|---|---|
| Weg | optional | Dies ist der Pfad der Unix-Domänen-Socket-Datei. Wenn das System Windows ist, wird dieser automatisch in eine entsprechende Pipe mit denselben Informationen wie die Unix-Domänen-Socket-Datei konvertiert. Wenn nicht festgelegt, wird standardmäßig ipc.config.socketRoot + ipc.config.appspace + id verwendet |
| Rückruf | optional | Dies ist eine Funktion, die nach dem Start des Servers aufgerufen wird. Dies kann auch durch die Bindung eines Ereignisses an das Startereignis erfolgen, z. B. ipc.server.on('start',function(){}); |
Beispielargumente können weggelassen werden, solange sie noch in Ordnung sind.
ipc . serve ( ) ;oder Rückruf angeben
ipc . serve (
function ( ) { ... }
) ;oder Pfad angeben
ipc . serve (
'/tmp/myapp.myservice'
) ;oder alles spezifizieren
ipc . serve (
'/tmp/myapp.myservice' ,
function ( ) { ... }
) ; serveNet(host,port,UDPType,callback)
Wird zum Erstellen eines TCP-, TLS- oder UDP-Socket-Servers verwendet, an den sich Clients binden oder an den andere Server Daten senden können. Der Server kann Ereignisse an bestimmte Client-Sockets emit oder Ereignisse an alle bekannten Client-Sockets broadcast .
| Variable | erforderlich | Definition |
|---|---|---|
| Gastgeber | optional | Wenn nicht angegeben, wird standardmäßig die erste Adresse in os.networkInterfaces() verwendet. Für TCP-, TLS- und UDP-Server ist dies höchstwahrscheinlich 127.0.0.1 oder ::1 |
| Hafen | optional | Der Port, an den der TCP-, UDP- oder TLS-Socket-Server gebunden wird. Der Standardwert ist 8000, wenn nicht angegeben |
| UDPType | optional | Wenn dies festgelegt ist, wird der Server als UDP-Socket erstellt. „udp4“ oder „udp6“ sind gültige Werte. Dies ist standardmäßig nicht festgelegt. Stellen Sie bei Verwendung von udp6 sicher, dass Sie einen gültigen IPv6-Host angeben, z. B. ::1 |
| Rückruf | optional | Funktion, die beim Erstellen des Servers aufgerufen werden soll |
Beispielargumente können weggelassen werden, solange sie noch in Ordnung sind.
Standard-TCP-Server
ipc . serveNet ( ) ;Standard-UDP-Server
ipc . serveNet ( 'udp4' ) ;oder Angabe eines TCP-Servers mit Rückruf
ipc . serveNet (
function ( ) { ... }
) ;oder Angabe eines UDP-Servers mit Rückruf
ipc . serveNet (
'udp4' ,
function ( ) { ... }
) ;oder Port angeben
ipc . serveNet (
3435
) ;oder alles TCP angeben
ipc . serveNet (
'MyMostAwesomeApp.com' ,
3435 ,
function ( ) { ... }
) ;oder alles UDP angeben
ipc . serveNet (
'MyMostAwesomeApp.com' ,
3435 ,
'udp4' ,
function ( ) { ... }
) ;| Variable | Definition |
|---|---|
| ipc.of | Hier werden Socket-Verbindungsreferenzen gespeichert, wenn eine Verbindung als Client über ipc.connectTo oder iupc.connectToNet hergestellt wird. Sie werden basierend auf der ID gespeichert, mit der sie erstellt wurden, z. B. ipc.of.mySocket |
| ipc.server | Dies ist ein Verweis auf den von ipc.serve oder ipc.serveNet erstellten Server |
| Verfahren | Definition |
|---|---|
| Start | Um mit der Bereitstellung zu beginnen, müssen Sie zuerst serve oder serveNet aufrufen, um den Server einzurichten |
| stoppen | Schließen Sie den Server und beenden Sie die Bereitstellung |
| Veranstaltungsname | Parameter | Definition |
|---|---|---|
| Fehler | Fehler obj | ausgelöst, wenn ein Fehler aufgetreten ist |
| verbinden | Wird ausgelöst, wenn die Steckdose angeschlossen ist | |
| trennen | Wird vom Client ausgelöst, wenn der Socket die Verbindung zum Server getrennt hat | |
| Steckdose.getrennt | Socket zerstörtSocketID | Wird vom Server ausgelöst, wenn die Verbindung zu einem Client-Socket getrennt wurde |
| zerstören | Wird ausgelöst, wenn der Socket vollständig zerstört wurde, es werden keine weiteren automatischen Wiederholungsversuche durchgeführt und alle Referenzen sind verschwunden. | |
| Daten | Puffer | Wird ausgelöst, wenn ipc.config.rawBuffer wahr ist und eine Nachricht empfangen wird. |
| Ihre Veranstaltungsart | Ihre Veranstaltungsdaten | Wird ausgelöst, wenn eine JSON-Nachricht empfangen wird. Der Ereignisname ist die Typzeichenfolge Ihrer Nachricht und der Parameter ist das Datenobjekt Ihrer Nachricht, z. B.: { type:'myEvent',data:{a:1}} |
Manchmal benötigen Sie möglicherweise explizite und unabhängige Instanzen von node-ipc. Speziell für solche Szenarien haben wir die IPC-Kernklasse im IPC-Singleton verfügbar gemacht.
import { IPCModule } from 'node-ipc' ;
const ipc = new RawIPC ;
const someOtherExplicitIPC = new RawIPC ;
//OR
const ipc = from 'node-ipc' ) ;
const someOtherExplicitIPC = new ipc . IPC ;
//setting explicit configs
//keep one silent and the other verbose
ipc . config . silent = true ;
someOtherExplicitIPC . config . silent = true ;
//make one a raw binary and the other json based ipc
ipc . config . rawBuffer = false ;
someOtherExplicitIPC . config . rawBuffer = true ;
someOtherExplicitIPC . config . encoding = 'hex' ;Erweiterte Beispiele finden Sie im Beispielordner. In den Beispielen finden Sie komplexere Demos inklusive Multi-Client-Beispielen.
Der Server ist der Prozess, der einen Socket für den IPC offen hält. Mehrere Sockets können sich mit diesem Server verbinden und mit ihm kommunizieren. Es kann auch an alle Clients oder an einen bestimmten Client gesendet werden. Dies ist das einfachste Beispiel, das für lokale Unix- und Windows-Sockets sowie lokale oder Remote-Netzwerk-TCP-Sockets funktioniert.
import ipc from 'node-ipc' ;
ipc . config . id = 'world' ;
ipc . config . retry = 1500 ;
ipc . serve (
function ( ) {
ipc . server . on (
'message' ,
function ( data , socket ) {
ipc . log ( 'got a message : ' . debug , data ) ;
ipc . server . emit (
socket ,
'message' , //this can be anything you want so long as
//your client knows.
data + ' world!'
) ;
}
) ;
ipc . server . on (
'socket.disconnected' ,
function ( socket , destroyedSocketID ) {
ipc . log ( 'client ' + destroyedSocketID + ' has disconnected!' ) ;
}
) ;
}
) ;
ipc . server . start ( ) ; Der Client stellt für die Interprozesskommunikation eine Verbindung zum Server-Socket her. Der Socket empfängt Ereignisse, die speziell an ihn gesendet werden, sowie Ereignisse, die vom Server an den Socket gesendet werden. Dies ist das einfachste Beispiel, das sowohl für lokale Unix-Sockets als auch für lokale oder Remote-Netzwerk-TCP-Sockets funktioniert.
import ipc from 'node-ipc' ;
ipc . config . id = 'hello' ;
ipc . config . retry = 1500 ;
ipc . connectTo (
'world' ,
function ( ) {
ipc . of . world . on (
'connect' ,
function ( ) {
ipc . log ( '## connected to world ##' . rainbow , ipc . config . delay ) ;
ipc . of . world . emit (
'message' , //any event or message type your server listens for
'hello'
)
}
) ;
ipc . of . world . on (
'disconnect' ,
function ( ) {
ipc . log ( 'disconnected from world' . notice ) ;
}
) ;
ipc . of . world . on (
'message' , //any event or message type your server listens for
function ( data ) {
ipc . log ( 'got a message from world : ' . debug , data ) ;
}
) ;
}
) ; UDP-Sockets unterscheiden sich von Unix-, Windows- und TCP-Sockets, da sie an einen eindeutigen Port auf ihrem Computer gebunden sein müssen, um Nachrichten zu empfangen. Beispielsweise könnte ein TCP-, Unix- oder Windows Socket-Client einfach eine Verbindung zu einem separaten TCP-, Unix- oder Windows Socket-Server herstellen. Dieser Client könnte dann Daten über den Port oder Standort des Servers senden und empfangen. UDP-Sockets können dies nicht. Sie müssen an einen Port gebunden sein, um Daten zu empfangen oder zu senden.
Das bedeutet, dass ein UDP-Client und ein UDP-Server dasselbe sind, denn um Daten zu empfangen, muss ein UDP-Socket über einen eigenen Port zum Empfangen von Daten verfügen und diesen Port kann jeweils nur ein Prozess verwenden. Dies bedeutet auch, dass der UDP-Server zum emit oder broadcast von Daten den Host und den Port des Sockets kennen muss, an den er die Daten senden möchte.
Dies ist das einfachste Beispiel, das sowohl für lokale als auch für Remote-UDP-Sockets funktioniert.
import ipc from 'node-ipc' ;
ipc . config . id = 'world' ;
ipc . config . retry = 1500 ;
ipc . serveNet (
'udp4' ,
function ( ) {
console . log ( 123 ) ;
ipc . server . on (
'message' ,
function ( data , socket ) {
ipc . log ( 'got a message from ' . debug , data . from . variable , ' : ' . debug , data . message . variable ) ;
ipc . server . emit (
socket ,
'message' ,
{
from : ipc . config . id ,
message : data . message + ' world!'
}
) ;
}
) ;
console . log ( ipc . server ) ;
}
) ;
ipc . server . start ( ) ; Beachten Sie, dass wir den Port hier auf 8001 setzen, da der Weltserver bereits den standardmäßigen ipc.config.networkPort von 8000 verwendet. Daher können wir keine Bindung an 8000 herstellen, während die Welt ihn verwendet.
ipc . config . id = 'hello' ;
ipc . config . retry = 1500 ;
ipc . serveNet (
8001 ,
'udp4' ,
function ( ) {
ipc . server . on (
'message' ,
function ( data ) {
ipc . log ( 'got Data' ) ;
ipc . log ( 'got a message from ' . debug , data . from . variable , ' : ' . debug , data . message . variable ) ;
}
) ;
ipc . server . emit (
{
address : '127.0.0.1' , //any hostname will work
port : ipc . config . networkPort
} ,
'message' ,
{
from : ipc . config . id ,
message : 'Hello'
}
) ;
}
) ;
ipc . server . start ( ) ; Binäre oder Puffer-Sockets können mit jedem der oben genannten Socket-Typen verwendet werden, die Art und Weise, wie Datenereignisse ausgegeben werden, unterscheidet sich jedoch geringfügig . Diese können nützlich sein, wenn Sie mit eingebetteten Systemen oder C-/C++-Prozessen arbeiten. Sie können sogar sicherstellen, dass die Zeichenfolgentypisierung in C oder C++ übereinstimmt.
Wenn Sie einen rawBuffer-Socket einrichten, müssen Sie ihn wie folgt angeben:
ipc . config . rawBuffer = true ; Sie können auch den Codierungstyp angeben. Der Standardwert ist utf8
ipc . config . encoding = 'utf8' ;String-Puffer ausgeben:
//server
ipc . server . emit (
socket ,
'hello'
) ;
//client
ipc . of . world . emit (
'hello'
)Byte-Array-Puffer ausgeben:
//hex encoding may work best for this.
ipc . config . encoding = 'hex' ;
//server
ipc . server . emit (
socket ,
[ 10 , 20 , 30 ]
) ;
//client
ipc . server . emit (
[ 10 , 20 , 30 ]
) ;Gibt Binär- oder Hex-Array-Puffer aus. Dies eignet sich am besten für die Datenübertragung in Echtzeit, insbesondere bei der Verbindung mit C- oder C++-Prozessen oder eingebetteten Systemen:
ipc . config . encoding = 'hex' ;
//server
ipc . server . emit (
socket ,
[ 0x05 , 0x6d , 0x5c ]
) ;
//client
ipc . server . emit (
[ 0x05 , 0x6d , 0x5c ]
) ;Das Schreiben expliziter Puffer, Int-Typen, Doubles, Floats usw. sowie Big-Endian- und Little-Endian-Daten in Rohpuffer ist besonders nützlich, wenn eine Verbindung zu C- oder C++-Prozessen oder eingebetteten Systemen hergestellt wird (siehe ausführlichere Informationen zu Puffern sowie UInt, Int , double usw. hier)[https://nodejs.org/api/buffer.html]:
ipc . config . encoding = 'hex' ;
//make a 6 byte buffer for example
const myBuffer = Buffer . alloc ( 6 ) . fill ( 0 ) ;
//fill the first 2 bytes with a 16 bit (2 byte) short unsigned int
//write a UInt16 (2 byte or short) as Big Endian
myBuffer . writeUInt16BE (
2 , //value to write
0 //offset in bytes
) ;
//OR
myBuffer . writeUInt16LE ( 0x2 , 0 ) ;
//OR
myBuffer . writeUInt16LE ( 0x02 , 0 ) ;
//fill the remaining 4 bytes with a 32 bit (4 byte) long unsigned int
//write a UInt32 (4 byte or long) as Big Endian
myBuffer . writeUInt32BE (
16772812 , //value to write
2 //offset in bytes
) ;
//OR
myBuffer . writeUInt32BE ( 0xffeecc , 0 )
//server
ipc . server . emit (
socket ,
myBuffer
) ;
//client
ipc . server . emit (
myBuffer
) ; cluster Modul node-ipc kann mit dem Clustermodul von Node.js verwendet werden, um die Möglichkeit zu bieten, mehrere Leser für einen einzelnen Socket zu haben. Dazu müssen Sie lediglich die unlink Eigenschaft in der Konfiguration auf false setzen und sich darum kümmern, die Verknüpfung des Socket-Pfads im Master-Prozess aufzuheben:
import fs from 'fs' ;
import ipc from 'node-ipc' ;
import { cpus } from 'os' ;
import cluster from 'cluster' ;
const cpuCount = cpus ( ) . length ;
const socketPath = '/tmp/ipc.sock' ;
ipc . config . unlink = false ;
if ( cluster . isMaster ) {
if ( fs . existsSync ( socketPath ) ) {
fs . unlinkSync ( socketPath ) ;
}
for ( let i = 0 ; i < cpuCount ; i ++ ) {
cluster . fork ( ) ;
}
} else {
ipc . serve (
socketPath ,
function ( ) {
ipc . server . on (
'currentDate' ,
function ( data , socket ) {
console . log ( `pid ${ process . pid } got: ` , data ) ;
}
) ;
}
) ;
ipc . server . start ( ) ;
console . log ( `pid ${ process . pid } listening on ${ socketPath } ` ) ;
} import fs from 'fs' ;
import ipc from 'node-ipc' ;
const socketPath = '/tmp/ipc.sock' ;
//loop forever so you can see the pid of the cluster sever change in the logs
setInterval (
function ( ) {
ipc . connectTo (
'world' ,
socketPath ,
connecting
) ;
} ,
2000
) ;
function connecting ( socket ) {
ipc . of . world . on (
'connect' ,
function ( ) {
ipc . of . world . emit (
'currentDate' ,
{
message : new Date ( ) . toISOString ( )
}
) ;
ipc . disconnect ( 'world' ) ;
}
) ;
} Siehe die MIT-Lizenzdatei.
Es tut mir Leid.
