Domanda

tutto quello che sto cercando di stabilire la comunicazione peer to peer (UDP) tramite estensione per Firefox. Ho programma Python che funziona su riga di comando. Ho costruito un componente XPCOM usarlo. Ma sorprendentemente ho potuto ricevere solo messaggi attraverso di essa dal programma Python da riga di comando.

Abbiamo cercato dopo (Tutte lavorando su localhost):

Firefox XPCOM componente come mittente -> Firefox XPCOM componente come ricevitore - non ha funzionato

Python linea di comando come mittente -> Firefox componente XPCOM come ricevitore - ha lavorato

Firefox componente XPCOM come mittente -> Python linea di comando come ricevitore - non ha funzionato

Python da riga di comando come mittente -> linea di comando python come ricevitore - ha lavorato

Quando abbiamo osservato i pacchetti usando Wireshark abbiamo ottenuto alcune differenze -

Firefox XPCOM alla linea di comando python e Firefox XPCOM per firefox XPCOM (che non ha funzionato) hanno record di pacchetti come segue

Tale tipo di pacchetti (porta sorgente contrassegnato come non numero) prodotto da

Winsock (C ++)

XPCOM componente

C #

...UDP  Source port: timbuktu-srv2  Destination port: 30000

riga di comando python alla linea di comando python E Python riga di comando per XPCOM (che ha lavorato) una registrazione con Pacchetto come segue

... UDP Source port: 30000  Destination port: 30000

Non so molto circa la messa in rete, ma il record segnato ..Source port: timbuktu-srv2.. non riesce a raggiungere la sua destinazione.

Ho cercato di comunicazione p2p con Python, C ++ (Winsock), C #, ma potrei riuscito solo con Python unica differenza che ho potuto osservare è tale tipo di record specifico con python ..

Can po 'di luce guru networking lampo su di esso?

È stato utile?

Soluzione

Il timbuktu-srv2 che stai vedendo è solo il risultato di Wireshark guardando il numero di porta effettivo contro la sua lista di servizi noti. Se si seleziona la IANA assegnato elenco numeri di porta , vedrete questa voce:

timbuktu-srv2   1418/udp   Timbuktu Service 2 Port

... in modo che significa semplicemente l'applicazione usata 1418 come porta sorgente del pacchetto UDP ha inviato. 30000 non viene trasformato in un nome di servizio di testo perché il database dei servizi locali non ha una voce per quel numero di porta.

Questo, di per sé, non spiega il problema - in realtà, il lato server dovrebbe accettare il client utilizzando qualsiasi porta di origine che vuole. Tuttavia, sembra probabile in questo caso che il lato ricevitore accetta solo i pacchetti con una porta sorgente di 30000. A tal fine, è necessario associare il socket all'indirizzo INADDR_ANY e porta locale 30000 prima di inviare il pacchetto (s).

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top