T50 multithreaded - experimental

15 views
Skip to first unread message

Frederico Lamberti Pissarra

unread,
Apr 6, 2014, 12:54:08 PM4/6/14
to t50...@googlegroups.com
Estarei colocando no github meu "port" do T50 usando pthreads ao invés de fork() no branch "experimental". Só não coloquei lá ainda porque ainda tem muitos bugs de compilação e ainda não funciona...

O "port" tá ficando meio "feioso" porque não quero ter que reescrever muita coisa, mas assim que eu tiver ele formatadinho e mais "bonitinho" faço um merge com "master", abandonando o fork. Isso vai demorar um bocado.

Algumas considerações:

1. sendto() é thread safe, mas, é claro, não é atomica... é necessário sincronismo!
2. random() não é thread safe, mas random_r() é... só tenho que manter estado por thread.
3. Um packet buffer por thread é necessário para manter as chamadas aos módulos thread safe.

Quanto à consideração 1, acho, que isso também é um possível bug do atual t50 se usado o modo turbo. Já que o socket descriptor é compartilhado pelos processos, não á garantias de overlapping nas chamadas à sendto().

[]s
Fred

klonez klonez

unread,
Apr 7, 2014, 8:26:48 AM4/7/14
to t50...@googlegroups.com
Fred,

Será que nestas mudanças vai facilitar ou dificultar o uso da libpcap ? Penso ainda na idéia de portar para outras plataformas, pelo menos, freeBSD e MacOS X.

sds
Kl0nEz


--
--
To post to this group, send email to t50...@googlegroups.com
To join this group, go to: http://groups.google.com/group/t50-dev
To support this project, go to: http://t50.sourceforge.net/

---
Você recebeu essa mensagem porque está inscrito no grupo quot;T50 Experimental Mixed Packet Injector Development" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para t50-dev+u...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

Frederico Pissarra

unread,
Apr 7, 2014, 1:51:31 PM4/7/14
to t50...@googlegroups.com
Dificultar não vai. De fato, estou tentando isolar as funções ao máximo, para evitar dependências desagradáveis.

O código, multithreaded, essencialmente é o mesmo, só que usa mecanismo de sincronismo nas chamadas à função sendto() para evitar overlapping (já que usa o mesmo socket descriptor - como citei no item 1, na mensagem original, acima).

O código ainda é experimental em dois sentidos:

1º - Não sei se sincronizar as threads nas chamadas a sendto() seja uma boa idéia, em termos de performance. Com isso estou "serializando-as" neste ponto (ou seja, quando uma está mandando, as outras estão esperando).

2º - Não sei se a aproximação que escolhi é a melhor... A outra idéia que tive era a de criar um "cache" de pacotes... A medida que as threads fossem montando os pacotes, os efilerariam e uma outra thread os "colheria" e enviaria. Isso poderia criar o problema de exaustão de memória, mas é uma coisa controlável, impondo-se um limite superior (onde as threads "parariam" até que o cache fosse esvaziado em algum ponto). Essa será a outra aproximação do código experimental... ISSO poderá dar um aumento de performance superior ao código atual do T50... Só que o código ficará um cadinho (há!) mais complexo!

[]s
Fred
Reply all
Reply to author
Forward
0 new messages