Самопрослушивание сокетов?

Тема в разделе "WASM.NETWORKS", создана пользователем Psionic, 30 авг 2011.

  1. Psionic

    Psionic Member

    Публикаций:
    0
    Регистрация:
    25 сен 2008
    Сообщения:
    156
    Есть задача померять трафик затрачиваемый приложением и померять точно. Можно ли это зделать - так одни компоненты приложения открывают сокеты и общаются с сервером, а другие компоненты (возможно из отдельного потока) открытые сокеты прослушивают? Платформа - *nix.
     
  2. r90

    r90 New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2005
    Сообщения:
    898
    Возьми ptrace и отследи все сисколлы, в особенности read/write/send/recv.
     
  3. Psionic

    Psionic Member

    Публикаций:
    0
    Регистрация:
    25 сен 2008
    Сообщения:
    156
    Процесс не может трассировать сам себя. Все должно происходит в рамках одного приложения.
     
  4. r90

    r90 New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2005
    Сообщения:
    898
    Ну форкни тогда свой процесс, и пускай родительский процесс мониторит использование ресурсов. Будут некоторые проблемы с выяснением того, какой файловый дескриптор сокет, а какой лишь пайп, но наверное это можно отследить перехватывая также open, pipe, socket, accept, и тп.

    Есть другой метод -- можно поигравшись с ld подменить glibc'овые функции-обёртки над сисколлами на свои. Я правда не могу дать подробной инструкции как это делать, но где-то я что-то читал на этот счёт. Кроме того, я могу порекомендовать посмотреть на libpth -- там этот подход используется как раз для замены read/write на более продвинутые версии.
    Но это сработает лишь если всякие разные компоненты полагаются на одни и те же библиотеки. Если же одни компоненты используют glibc'овые обёртки над сисколлами, другие компоненты работают поверх glib, третьи работают непосредственно с сисколлами -- то ничего хорошего из этого не выйдет.

    А, есть ещё один хитрый подход, но для него нужны рутовские права: можно запрячь iptables посчитать трафик данного процесса.