[Python 3] TCP Socket "flush"

[demos88]

Ciao, ho iniziato da qualche giorno a giocherellare con il Python, giusto perchè mi serve per la tesi di laurea.
Per l'applicazione che devo scrivere, devo usare dei socket TCP per mandare dei comandi a un host remoto.
Sto provando in locale a vedere come funzionano i socket in Python usando anche soluzioni ibride Java/Python (un host Java e l'altro Python) e bene o male funzionano correttamente.
C'è solo un piccolo dubbio/problema che mi affligge.
Quando devo mandare una riga di plain text (che rappresenta un comando), mi serve che questa sia immediatamente spedita e quindi letta dalla destinazione.
Ma ho notato che il socket Python che senda la stringa, non sempre la spedisce subito.
Giusto per dirla in termini più immediati: se io faccio consecutivamente due socket.send() di due stringhe diverse, dall'altra parte non ricevo nulla fino a che lo script non è finito, e ricevo comunque le due stringhe insieme nella stessa riga.
Io vorrei avere un pacchetto TCP per ogni stringa che sendo, una specie di flush del buffer in uscita (e in entrata?)

[demos88]

Fatto qualche prova, forse il problema non sussiste, ho notato che l'output su console può essere ingannevole per via del fatto che spedisco stringhe senza carattere di newline quindi l'output sembra un unico blocco quando magari sono più di uno.
Comunque, giusto per conoscenza, socket.send() mi assicura che ogni chiamata ad esso forgia un messaggio che viene spedito subito oppure no? Intanto faccio altre prove...

[banryu79]

Originariamente inviato da demos88

Comunque, giusto per conoscenza, socket.send() mi assicura che ogni chiamata ad esso forgia un messaggio che viene spedito subito oppure no? Intanto faccio altre prove...

Ciao, per quel poco che ne so di TCP, direi di no (a prescindere da Python, Java o linguaggio).

[cdimauro]

Il modulo socket è soltanto un binding (di basso livello) per manipolare i socket in Python. Non viene effettuato alcuno buffering.

Il metodo send è, quindi, un wrapper alla classica send che si trova in C, Java, ecc..

P.S. Scusate per la brevità delle risposte, ma ho pochissimo tempo a disposizione.

[!fazz]

Originariamente inviato da demos88

Fatto qualche prova, forse il problema non sussiste, ho notato che l'output su console può essere ingannevole per via del fatto che spedisco stringhe senza carattere di newline quindi l'output sembra un unico blocco quando magari sono più di uno.
Comunque, giusto per conoscenza, socket.send() mi assicura che ogni chiamata ad esso forgia un messaggio che viene spedito subito oppure no? Intanto faccio altre prove...

usare wireshark per controllare è l'unica soluzione fattibile e sicura

[demos88]

Originariamente inviato da banryu79

Ciao, per quel poco che ne so di TCP, direi di no (a prescindere da Python, Java o linguaggio).

Originariamente inviato da cdimauro

Il modulo socket è soltanto un binding (di basso livello) per manipolare i socket in Python. Non viene effettuato alcuno buffering.

Il metodo send è, quindi, un wrapper alla classica send che si trova in C, Java, ecc..

I due pareri mi sembrano divergenti, tuttavia ora che ci penso un attimo, l'utilizzo (che windows 7 fa) dell'algoritmo di Nagle potrebbe in qualche modo interferire creando un solo pacchetto o più pacchetti in relazione a quanto tempo intercorre fra un send e l'altro.
Ma se il socket di python è un wapper al socket nudo e crudo, allora sarei tentato a pensare che effettivamente ogni send possa corrispondere a singoli pacchetti, salvo, come detto sopra, intromissioni.

Originariamente inviato da !fazz

usare wireshark per controllare è l'unica soluzione fattibile e sicura

A questo punto lo penso anche io, proverò anche smanettando un po' con le impostazioni più profonde della scheda di rete.

Grazie per le risposte

[marco.r]

Originariamente inviato da demos88

I due pareri mi sembrano divergenti

No, cdimauro ha detto che _python_ non fa buffering. Poi dipende da quello che fa la libreria C e il sistema operativo.
In ogni caso in un socket stream-oriented tipo TCP non hai alcuna garanzia che una send venga fatta in un unico messaggio (potrebbe venire spezzato se troppo grande per la dimensione del pacchetto) o che piu' send possano venire accorpate in un unico pacchetto.
Diverso sarebbe se tu usassi un socket message-oriented come UDP.

Per poter far si che il messaggio "parta" come pacchetto ad ogni send puoi aprire il socket con l'opzione TCP_NODELAY, che evita l'attesa introdotta dall'algoritmo di Nagle.
In alternativa anche forzare un flush del socket potrebbe bastare (ma non ne sono sicuro).

[cdimauro]

Dal modulo socket.py di Python 3.2:

class socket(_socket.socket):

    """A subclass of _socket.socket adding the makefile() method."""

    __slots__ = ["__weakref__", "_io_refs", "_closed"]

    def __init__(self, family=AF_INET, type=SOCK_STREAM, proto=0, fileno=None):
        _socket.socket.__init__(self, family, type, proto, fileno)
        self._io_refs = 0
        self._closed = False

_socket è il modulo C che funge da wrapper per le classiche API BSD.

La send è il metodo, scritto come funzione C (sock_send, esportata dal modulo _socket come metodo send), che richiama l'equivalente API BSD (dal file socketmodule.c):

n = send(s->sock_fd, buf, len, flags);

recuperata tramite

#include sys/socket.h

Per cui sono relativamente sicuro che non ci sia nulla in mezzo.

[banryu79]

Originariamente inviato da marco.r

No, cdimauro ha detto che _python_ non fa buffering. Poi dipende da quello che fa la libreria C e il sistema operativo.

Volevo dire che anche per Java è così.
La libreria fornisce dei precotti per i casi d'uso più comuni.
Ad esempio ci sono java.net.SSLSocket e java.net.SSLServerSocket che poi non sono altro che specializzazioni di java.net.Socket/java.net.ServerSocket per TCP. C'è poi java.net.DatagramSocket per UDP.

le varie classi Socket/DatagramSocket delegano il "vero" lavoro alle astrazioni java.net.SocketImpl e java.net.DatagramSocketImpl: ogni piattaforma fornisce la propria specifica implementazione di queste due classi astratte.
Queste implementazioni platform-specific concretizzano (implementano) l'interfaccia comune e trasversale: java.net.SocketOptions.

E in SocketOprions troviamo opzioni per i socket molto specifiche tra cui alcune significative, tipo: SO_RCVBUF, SO_SNDBUF e TCP_NODELAY.
Queste non sono relative a Java, ma alla piattaforma/sistema su cui gira la vm, ad esempio il javadoc di SO_RCVBUF recita:

static final int SO_RCVBUF

Set a hint the size of the underlying buffers used by the platform for incoming network I/O. When used in set, this is a suggestion to the kernel from the application about the size of buffers to use for the data to be received over the socket. When used in get, this must return the size of the buffer actually used by the platform when receiving in data on this socket. Valid for all sockets: SocketImpl, DatagramSocketImpl

Qua ho trovato delle vecchie FAQ (ma sospetto dal contenuto ancora valido) a uso e consumo di demos88