2014-09-06 19:02 GMT+02:00 Roberto De Ioris :
>
> > rispondo e per me chiudo il thread:
> >
> > Il thread era il bug (vedi oggetto) di MSG_OOB e non l'affidabilità dei
> > protocolli di rete. Che poi, i nostri cari protocolli, a qualunque
> livello
> > delle stack, sono tutti un buco.
> >
>
> Va b
Marco Beri :
> Lo fa anche Gmail.
intendi il + in basso alla mail? e che ci vuole la "volontà" per cliccarci
sopra? è un po' sottostimata sta parola :-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
> rispondo e per me chiudo il thread:
>
> Il thread era il bug (vedi oggetto) di MSG_OOB e non l'affidabilità dei
> protocolli di rete. Che poi, i nostri cari protocolli, a qualunque livello
> delle stack, sono tutti un buco.
>
Va bene, ma almeno la curiosita' di sapere cosa volevi fare potevi
to
On Sep 6, 2014 9:23 PM, "Remo The Last" wrote:
> Chiudo dicendo che purtroppo sto su yahoo e che per rispondere al thread,
yahoo si trasporta tutta la conversazione. Me ne andrò su libero.it
prossimamente o altra email.
Lo fa anche Gmail.
Ma con un po' di buona volontà si riesce a fare tutto.
rispondo e per me chiudo il thread:
Il thread era il bug (vedi oggetto) di MSG_OOB e non l'affidabilità dei
protocolli di rete. Che poi, i nostri cari protocolli, a qualunque livello
delle stack, sono tutti un buco.
Chiudo dicendo che purtroppo sto su yahoo e che per rispondere al thread, yahoo
2014-09-06 15:28 GMT+02:00 Giampaolo Rodola' :
>
> 2014-09-06 14:50 GMT+02:00 Manlio Perillo :
>
>> 2014-09-06 14:02 GMT+02:00 Remo The Last :
>>
>>> Manlio, stai scherzando vero?
>>> Stai dicendo che il trasporto udp è più affidabile del tcp (best effort)?
>>> ciacia
>>>
>>>
>>> No. Sto dicendo c
2014-09-06 14:50 GMT+02:00 Manlio Perillo :
> 2014-09-06 14:02 GMT+02:00 Remo The Last :
>
>> Manlio, stai scherzando vero?
>> Stai dicendo che il trasporto udp è più affidabile del tcp (best effort)?
>> ciacia
>>
>>
>> No. Sto dicendo che se vuoi dialogare tramite "messaggi" o usi
> SOCK_STREAM c
2014-09-06 14:02 GMT+02:00 Remo The Last :
> Manlio, stai scherzando vero?
> Stai dicendo che il trasporto udp è più affidabile del tcp (best effort)?
> ciacia
>
>
> No. Sto dicendo che se vuoi dialogare tramite "messaggi" o usi SOCK_STREAM
con un dato protocollo, oppure usi SOCK_DGRAM. Se ti sen
Manlio, stai scherzando vero?
Stai dicendo che il trasporto udp è più affidabile del tcp (best effort)?
ciacia
Il Venerdì 5 Settembre 2014 12:04, Manlio Perillo ha
scritto:
2014-09-04 12:19 GMT+02:00 Remo The Last :
Buongiorno lista.
>Continuando la mia programmazione relativa all'invio d
2014-09-04 12:19 GMT+02:00 Remo The Last :
> Buongiorno lista.
> Continuando la mia programmazione relativa all'invio di segnali hex, ho
> potuto confermare quanto letto in linea che un server python con flag
> MSG_OOB
>
Perchè mai usi MSG_OOB, ossia messaggi fuori banda, la cui semantica è
impl
1. utilizzo l'invio di messaggi in esadecimale per dare comandi tipo ctrl-c,
ctrl-alt-\, alt-F4 ecc. a macchine remote. Ed è anche poco etico. Sono dei veri
e propri segnali in esadecimale a seguito della mappatura della tastiera e
visualizzazione delle tabelle in linea di messaggi in hex
2.
> Buongiorno lista.
> Continuando la mia programmazione relativa all'invio di segnali hex, ho
> potuto confermare quanto letto in linea che un server python con flag
> MSG_OOB crasha sempre. E questa è una conferma.
>
> Ma è anche vero che un socket client con flag MSG_OOB taglia a destra di
> un
Buongiorno lista.
Continuando la mia programmazione relativa all'invio di segnali hex, ho potuto
confermare quanto letto in linea che un server python con flag MSG_OOB crasha
sempre. E questa è una conferma.
Ma è anche vero che un socket client con flag MSG_OOB taglia a destra di un
byte il mes
>Il problema e` che che su ambienti *nix (o meglio, su Linux, visto che
non
>ho altri sistemi *nix su cui provare ;) ) non solo funziona bene, ma
basta
>un CTRL + C (SIGINT) per terminare il processo ed avere di nuovo la shell
>libera.
Ahemmm... Ctrl + Break?
(Ctrl + Fn + Fine sulla mia tastier
On 05/26/2014 12:57 PM, Enrico Bianchi wrote:
C'e` un modo per aggirare questa cosa che non sia "abbandona Windows"? :)
Ok, smanettando, anche grazie all'aiuto su irc di Manlio, sono arrivato
ad una soluzione. Per essere piu` precisi rispetto ai miei precedenti
messaggi, il mio problema era che
2014-05-26 12:57 GMT+02:00 Enrico Bianchi :
> Ultimamente mi sto scontrando cone le idiosincrasie di Windows senza
> trovare una via di uscita. Prendiamo in esame il seguente codice:
>
>
> > [...]
> Il codice non e` altri che un normale echo server, che apre il suo socket
> e si mette in ascolto
2014-05-26 14:36 GMT+02:00 Enrico Bianchi :
> On 05/26/2014 02:30 PM, Manlio Perillo wrote:
>
>> Si, ed è quello di replicare quello che succede su un sistema UNIX.
>>
>
> Mmm... questo vale anche per i programmi che girano come servizio (da
> questo punto di vista sono stato impreciso nel messagg
On 05/26/2014 02:30 PM, Manlio Perillo wrote:
Si, ed è quello di replicare quello che succede su un sistema UNIX.
Mmm... questo vale anche per i programmi che girano come servizio (da
questo punto di vista sono stato impreciso nel messaggio precedente e me
ne scuso, a me serve far girare l'ap
2014-05-26 12:57 GMT+02:00 Enrico Bianchi :
> Ultimamente mi sto scontrando cone le idiosincrasie di Windows senza
> trovare una via di uscita. Prendiamo in esame il seguente codice:
>
> > [...]
>
> Il codice non e` altri che un normale echo server, che apre il suo socket
> e si mette in ascolto
Ultimamente mi sto scontrando cone le idiosincrasie di Windows senza
trovare una via di uscita. Prendiamo in esame il seguente codice:
import socket
host = ''
port = 5
backlog = 5
size = 1024
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((host,port))
s.listen(backlog)
while 1
Sto tentando "ricreare" un client telnet in Python. Quando provo a
connettermi su un server FTP, mi arriva il messaggio di benvenuto, poi
attende un input per inviare un comando. Il messaggio credo che arrivi,
solo che non riceve niente come risposta (mentre con Telnet ho provato gli
stessi comandi
On Friday, March 23, 2012 07:40:52 PM Enrico 'Henryx' Bianchi wrote:
> while True:
> data = conn.makefile().readline()
> if not data:
> break
> datajson = json.loads(data.decode("utf-8"))
Ok, grazie anche ad una risposta su usenet (e` bello vedere che nonostante
tutto ancora
On Sat, 24 Mar 2012 19:26:40 +0100, Enrico 'Henryx' Bianchi wrote:
Comunque usando i socket a basso livello ci sono molte cose a cui
badare.
Eh, me ne sono accorto. Ora, pur non volendo fare il polemico, non
posso fare a
meno di notare che di questi problemi con i socket Java non ne ho mai
ris
On Saturday, March 24, 2012 02:41:36 PM Manlio Perillo wrote:
> Se sei sicuro che \n non compaia all'interno della stringa, allora sei a
> posto.
Sono altamente sicuro, in quanto la stringa e` generata dal modulo json
partendo dai dati presenti su di un dizionario, che di default e` generata
senz
On Saturday, March 24, 2012 01:21:28 PM Enrico 'Henryx' Bianchi wrote:
> In teoria potrei
> risolvere facendo il controllo della corretta lunghezza della stringa (if
> (data[:2] == '["' or data[:3] == '[{"') and (data[-3:] == '}]\n')) ed
> inviare al client un comando di notifica che, in caso ne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 24/03/2012 13:21, Enrico 'Henryx' Bianchi ha scritto:
> On Friday, March 23, 2012 08:31:50 PM Manlio Perillo wrote:
>> Su IRC ricordo di averti consigliato di studiare le Netstrings, o simili.
>
> Si, ricordo anche io di questa discussione (di cui,
mi sembra di aver bufferizzato un paio di anni fa
guarda qui se trovi l'ispirazione
http://stackoverflow.com/questions/822001/python-sockets-buffering
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
On Friday, March 23, 2012 08:31:50 PM Manlio Perillo wrote:
> Su IRC ricordo di averti consigliato di studiare le Netstrings, o simili.
Si, ricordo anche io di questa discussione (di cui, pero`, non trovo traccia
nei miei log, probabilmente l'abbiamo fatta quando ero a lavoro), il fatto e`
che b
On Fri, 23 Mar 2012 19:40:52 +0100, Enrico 'Henryx' Bianchi wrote:
Mi ritrovo con un problema rognoso nella lettura dei dati via socket.
Via
client, uso questi metodi per inviare i dati:
[...]
for item in res.get():
conn.send(item + "\n")
send() non garantisce di inviare tutto quello che
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 23/03/2012 19:40, Enrico 'Henryx' Bianchi ha scritto:
> Mi ritrovo con un problema rognoso nella lettura dei dati via socket. Via
> client, uso questi metodi per inviare i dati:
>
> def get(self):
>[... a great effort ...]
>yield json.dump
Mi ritrovo con un problema rognoso nella lettura dei dati via socket. Via
client, uso questi metodi per inviare i dati:
def get(self):
for item in self._directory:
for root, dirs, files in os.walk(item.encode("utf-8")):
for directory in dirs:
path = os.path
Il giorno 15/lug/2011, alle ore 08.37, Simone Ziraldo ha scritto:
>> il fatto che sia wi-fi è un dettaglio implementativo, fosse via cavetto
>> ethernet il discorso sarebbe esattamente lo stesso
>> (scusa è che se no sembra che le socket abbiano a che fare esclusivamente
>> con le connessioni w
> il fatto che sia wi-fi è un dettaglio implementativo, fosse via cavetto
> ethernet il discorso sarebbe esattamente lo stesso
> (scusa è che se no sembra che le socket abbiano a che fare esclusivamente con
> le connessioni wi-fi quando invece sono un astrazione moolto più generale
> generale)
s
2011/7/14 Simone Ziraldo
> Se durante lo sleep di 15 secondi chiudo la connessione WiFi il server non
> si accorge di niente e rimane ad aspettare su conn.recv(1024)...come posso
> risolvere questo problema? Avete qualche idea?
>
ehm non si tratta di una connessione wi-fi bensì di una connession
Ciao a tutti,
avrei bisogno di un aiuto. Vorrei trasferire dei dati tra due pc via wireless e
pensavo di ricorrere ai socket.
Fin qui tutto bene. Tra client e server c'è una connessione WiFi molto
instabile e potrebbe anche cadere per qualche secondo/minuto.
Il problema dei socket è che, se la co
Salve a tutti...vorrei porvi un quesito... sto creando un port scanner
ma nei "log" fatti da me riscontro che è davvero lento perchè testa la
connessessione sulla porta(anche se chiusa) diverse volte...c'è un modo
per imporgli di testare la connessione per esempio sulla porta 80 solo
una volta..cos
Manlio Perillo ha scritto:
[...]
Hai due soluzioni:
1) Leggere la risposta linea per linea.
2) Leggere tutta, ma proprio tutta, la risposta
In entrambi i casi la soluzione più semplice è usare
sock.makefile('rb', 0)
Vedi ad esempio l'implementazione del modulo httplib.
Per leggere una linea a
Il 30/07/07, Manlio Perillo<[EMAIL PROTECTED]> ha scritto:
> Se una cosa del genere è scritta nel reference di php, mi vengono i
> brividi...
Figuriamoci a Nicola!
--
Alan Franzoni <[EMAIL PROTECTED]>
-
GPG Key Fingerprint:
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
__
allanon ha scritto:
[...]
ghghghg, grazie ad un coder php abbiamo risolto!!
(lui dice che nel reference del php c'e' scritto!!!)
Se una cosa del genere è scritta nel reference di php, mi vengono i
brividi...
> [...]
Saluti Manlio Perillo
___
Py
allanon ha scritto:
Eccomi qua, con un altro quesito!
siccome sono niubbo il codice lo provo prima nell'interprete ide
(quello che si lancia scrivendo python da console :p)
e allora scrivo questo codice qui
#!/usr/bin/python
import sys
from socket import *
import re
Host = 'localhost'
Port = 5
Thu 26 July 2007, alle 23:35 +0200, allanon ha scritto:
> Eccomi qua, con un altro quesito!
>
> siccome sono niubbo il codice lo provo prima nell'interprete ide
> (quello che si lancia scrivendo python da console :p)
>
> e allora scrivo questo codice qui
>
> #!/usr/bin/python
> import sys
> from
Eccomi qua, con un altro quesito!
siccome sono niubbo il codice lo provo prima nell'interprete ide
(quello che si lancia scrivendo python da console :p)
e allora scrivo questo codice qui
#!/usr/bin/python
import sys
from socket import *
import re
Host = 'localhost'
Port = 5038
s = socket(AF_INET
42 matches
Mail list logo
