Connexion telnet aléatoire de routeur et mediabox - Page 1

Edited_4056

C'est probablement le cas, ouais.

en général, les gens en sont complètement inconscient vu que le routeur s'ouvre souvent par upnp pour ce type de "brèches"

Edited_4057

write et read ne retourne pas la quantité d'octet écrit avec succès ?

Edited_4058

Ce n'est pas lié à ça ?
http://stackoverflow.com/questions/2216374/why-is-writing-a-closed-tcp-socket-worse-than-reading-one

Edited_4059

http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-2.html#ss2.8
2.8 Why does it take so long to detect that the peer died?
(...)If you're sending to the peer, though, you have some better guarantees; since sending data implies receiving ACKs from the peer, then you will know after the retransmit timeout whether the peer is still alive. But the retransmit timeout is designed to allow for various contingencies, with the intention that TCP connections are not dropped simply as a result of minor network upsets. So you should still expect a delay of several minutes before getting notification of the failure.[/b]

Donc apparemment ça peut potentiellement prendre plusieurs minutes pour détecter que la connexion n'est plus fonctionnelle (je suppose que c'est quand la connexion réseau meurt, pas quand elle est fermée proprement par l'autre machine).

Donc soit tu réduis le timeout (mais je ne sais pas si chaque application peut le contrôler, ou si c'est un réglage système), soit tu utilises des sockets non bloquants. Je te recommande la seconde option, vu que de toute façon tu vas être obligé de le faire si tu veux supporter plus d'une connexion à la fois (à moins que t'inventes une BBS à un seul utilisateur en même temps )

Edited_4060

Y'a du fric à se faire avec des botnets, et quand il y a du fric tu trouveras toujours quelqu'un pour mettre les moyens.

Sinon, beuah, fork
(tu fais du Linux maintenant ?)

Edited_4061

Qui l'eut crû ^^