LwIP - netconn API - Invia un pacchetto TCP mentre il processo è bloccato?

Question

Sto usando FreeRTOS + LwIP per sviluppare un dispositivo di chiamata infermiera da comodino basato su Ethernet. Dopo aver letto alcuni esempi e documenti, desidero utilizzare l'API netconn di LwIP per inviare e ricevere dati su TCP, perché non ho familiarità con l'API di stile BSD e l'API raw potrebbe essere difficile.

so la funzione netconn_accept() bloccherà il processo fino a una richiesta di connessione da un host remoto arrivato, e la funzione netconn_recv() sarà anche bloccare il processo in attesa di ricezione di dati ... entrambe queste funzioni saranno blocco la processo, è buono per un server che riceve i dati, tuttavia, il mio dispositivo deve anche fungere da client che deve attivare una "chiamata" al centro infermieristico quando il paziente preme un pulsante. Quindi, come può iniziare a inviare un pacchetto TCP mentre è in attesa anche di una connessione (bloccando il processo) dall'host remoto?

Ho bisogno di inviare TCP perché devo usare SIP (Session Initiation Protocol) per iniziare una chiamata, il dovrebbe essere affidabile perché è un dispositivo medico. La ringrazio molto

---

@ Kyle Heironimus, @werewindle si aggiungo alla mia domanda, perché so che hai esperienza sul LwIP, la speranza che non vi farà disagi e la speranza che si può aiutare, vi ringrazio.

Answer 1

Non è possibile inviare dati a un host remoto prima di aver avviato una connessione. Questo non ha alcun senso. La mia domanda è: vuoi che il tuo dispositivo si connetta all'host remoto o vuoi che l'host remoto avvii una connessione al tuo dispositivo?

In questo momento si sta utilizzando netconn_accept nel dispositivo. Ciò significa che si sta aspettando che l'host remoto avvii una connessione al dispositivo prima che il dispositivo possa segnalare l'host remoto. Questo è un comportamento del tutto atteso per il codice che hai scritto, ma sembri preoccupato per questo. Non è questa la tua intenzione? In caso contrario, perché l'hai codificato in questo modo? L'altra alternativa è di avere il dispositivo in uso per avviare la connessione all'host remoto. C'è un esempio di quell'uso di netconns here. Ovviamente ciò comporta anche modifiche all'altro dispositivo nel sistema.

Quindi la morale di questa storia è che non è possibile inviare alcun dato quando non è presente alcuna connessione e si sta aspettando una connessione prima di inviare i dati. Non si desidera attendere la connessione, quindi è necessario modificare il software per avviare la connessione, piuttosto che attendere l'altro lato per avviarlo.

Un altro problema che potresti incontrare è che vuoi essere in grado di inviare e ricevere dati sulla stessa connessione allo stesso tempo. La maggior parte degli esempi che ho visto per lwip riguarda il blocco delle chiamate in attesa di dati, quindi la risposta a tali dati mediante la trasmissione di qualcosa. A volte vuoi trasmettere qualcosa senza prima ricevere qualcosa. Posso aiutare anche con quello.

Questo è ciò che ha funzionato per me quando ho creato una connessione di ascolto netconn.

In primo luogo, è necessario attivare timeout impostando:

# define LWIP_SO_RCVTIMEO 1

Allora dovete impostare i netconn simile a questa:

pxTCPListener = netconn_new (NETCONN_TCP);

netconn_bind (pxTCPListener, NULL, 23);

netconn_listen (pxTCPListener);

pxNewConnection = netconn_accept (pxTCPListener); // Questo blocca fino a quando la connessione è accettata

// Questa è la linea importante!

pxNewConnection-> recv_timeout = 10; // notare che questo è millseconds - lwip lavora in ms

// Questo loop fino a quando la connessione è chiusa

mentre (ERR_IS_FATAL (pxNewConnection-> err)!) {// Errori fatali includono connessioni essendo chiusi, reset , abortito, ecc

// Questa chiamata netconn_recv sarà ora attendere 10 ms per tutti i nuovi dati, per poi tornare

if ((pxRxBuffer = netconn_recv (pxNewConnection))! = null) {

// Gestire ricevere Dati d

}

// Qui, effettuare una trasmette desideri

} // Fine del ciclo while dall'alto

Quel codice vi permetterà di fare trasmette e riceve in allo stesso tempo senza preoccuparsi di bloccare.