Няшная / Говнокод #27259 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
static int callback_from_db_message(void *data, int argc, char **argv, char **azColName) {
    int *userSocket = data;
    long time = atol(argv[1]);
    bool edit = atoi(argv[2]);
    char *sTime = mx_strnew(26);
    ctime_r(&time, sTime);
    char *buffer = new_messageClient1(argv[0], argv[3],sTime,edit);
    usleep(10000);
    int receive = send(*userSocket, buffer, mx_strlen(buffer), 0);

    return argc - argc + mx_strlen(azColName[0] ? "" : "0") - mx_strlen(azColName[0] ? "" : "0");
}

Компилятор жалуется, что не используется переменная?
И при быстром отправке в сокет, сообщения соединяются в один?
Вот решение!

Запостил: lord_c lord_c, (Updated )

Комментарии (18) RSS

    • ava bormand # Ссылка на оригинал 0 ⇈

      Ну а хули, для мелких пакетов работает. Крупные один хер пополам разваливаться начнут, вот тогда по-нормальному разберётся в проблеме.
      Ответить

  • ava bormand # Ссылка на оригинал 0

    > при быстром отправке в сокет, сообщения соединяются в один

    Это нормально. А иногда наоборот могут на 2 пакета развалиться и половинками придти. TCP сокет -- это поток байтов без чётких границ между ними.

    Deal with it.
    Ответить

    • ava MAPTbIwKA # Ссылка на оригинал 0 ⇈

      Можно перейти на UDP. Они вроде не разваливаются на пакеты, если не разрешать фрагментацию
      Ответить

      • ava bormand # Ссылка на оригинал 0 ⇈

        Да даже если и разрешать... read только полностью собранные udp'шки тебе возвращает.
        Ответить

        • ava MAPTbIwKA # Ссылка на оригинал 0 ⇈

          Да, фрагментация идет уровне ниже, но фрагментированные пакеты никуда не дойдут в современном Интернете, думаю.

          Я к тому, что если если sendto в UDP более допустимного размера пакета (в случае запрета фрагментаци размер наверное ограничен MTU), то тебе дадут пососать EMSGSIZE , не?
          Ответить

          • ava bormand # Ссылка на оригинал 0 ⇈

            Ну если больше 65к кинешь -- наверное.

            А про MTU и запрет фрагментации не уверен. Скорее молча дропнет и/или какое-нибудь ICMP кинет в ответ, на которое всем пофиг. Ну короче я бы не надеялся на внятную ошибку тут.
            Ответить

            • ava MAPTbIwKA # Ссылка на оригинал 0 ⇈ 

              By default, Linux UDP does path MTU (Maximum Transmission Unit)
       discovery.  This means the kernel will keep track of the MTU to a
       specific target IP address and return EMSGSIZE when a UDP packet
       write exceeds it.  When this happens, the application should
       decrease the packet size.

              https://man7.org/linux/man-pages/man7/udp.7.html

              Но там дальше написано, что можно и отключить.
              Ответить

              • ava bormand # Ссылка на оригинал 0 ⇈

                > By default
                > Linux

                Ну ты понел. Т.е. ошибку получить можно, но гарантий тут никаких, может и молча дропнуть по дороге.
                Ответить

                • ava MAPTbIwKA # Ссылка на оригинал 0 ⇈

                  ну это понятно.

                  Случайная ОС может отлично фрагментнуть твой пакет, и послать его в далнее плавание, где его ебанёт первый маршрутизатор, не послав в ответ никакого ICMP.

                  Будет такая черная дыра. Собссно, ради этого MTU black hole discovery и запилили.

                  Но в UDP вообще никаких гарантий нет:) Ты просто пишшеь себе, и надеешься, что оно куда-то дойдет
                  Ответить

                  • ava bormand # Ссылка на оригинал 0 ⇈

                    Ну если в 500 байт уложиться, то вроде есть какая-никакая гарантия, что хотя бы попытаются доставить...
                    Ответить

                    • ava MAPTbIwKA # Ссылка на оригинал 0 ⇈

                      576 байт вроде минимально допустимый MTU для IPv4.
                      Но там еще часто идет на заголовок IP, и на всякие порты UDP, так что наверное ты прав, где-то 500
                      Ответить

                  • ava Fike # Ссылка на оригинал 0 ⇈

                    > Ты просто пишшеь себе, и надеешься, что оно куда-то дойдет

                    а, так вот как форма на kremlin.ru работает
                    Ответить

              • ava bormand # Ссылка на оригинал 0 ⇈

                Опять же, откуда твоё ядро знает, какое там MTU по дороге? Разве что по ICMP ответам, на которые все ложат хуй. Кто-нибудь по дороге проебёт это ICMP и ты никогда и не узнаешь, что пакет великоват был.
                Ответить

                • ava MAPTbIwKA # Ссылка на оригинал 0 ⇈

                  >Опять же, откуда твоё ядро знает, какое там MTU по дороге?
                  Ну Борманд, ты же старый админ
                  https://tools.ietf.org/html/rfc1191

                  >Разве что по ICMP ответам, на которые все ложат хуй.
                  Есть такое. И тогда MTU приходится вручную уменьшать.

                  У меня такое было пару раз: вроде работает Интернет, но хуёво. Значит, какой-то пидор по дороге грохает пакет без отсылки ICMP. Уменьшаешь MTU -- работает хорошо.
                  Ответить

    • ava Fike # Ссылка на оригинал 0 ⇈

      > А иногда наоборот могут на 2 пакета развалиться и половинками придти. TCP сокет -- это поток байтов без чётких границ между ними.

      О, про это тоже смешная история была. Приходит как-то в @elasticsearch_ru человек и спрашивает: Ребят, а у меня почему-то логи длиннее килобайта не приходят, в чем дело? В смысле зачем я TCP input выбрал?
      Ответить

      • ava bormand # Ссылка на оригинал 0 ⇈

        Да про это, я думаю, у каждого свои смешные истории были...

        Я сам когда-то налетал на эти грабли когда свою первую прогу с сетью писал. Мелкие редкие сообщения то норм доходят.
        Ответить

        • ava hormand # Ссылка на оригинал 0 ⇈

          Да иди ты нахуй отсюда! Зачем вернулся, слова не сдержал?
          Ответить

Добавить комментарий

Из-за тебя ушел bormand, guest!

    А не использовать ли нам bbcode?

    ↑
    8
    ↓