Очень длинная ошибка

Я отправляю из .Net-приложения 1404 значения с плавающей запятой, которые составляют 5616 байт через сокет udp. Я не исключаю исключений из этой операции.

Однако программа, получающая эти данные, является приложением С++, и при получении такого количества данных я получаю сообщение об ошибке 10040 слишком долго.

По-видимому, 1480 байтов является самым длинным размером для сообщений в Wsock2.

Каким будет самый простой, самый чистый способ исправить это?

Спасибо!

EDIT: Проводка кода:

Это мой сокет. Класс J_Receive:

#include "J_Receive.h"


#include <stdio.h>
#include <fcntl.h>
#include <sys/types.h>
#if defined (WIN32) && !defined(__CYGWIN__)
#include <winsock.h>
#else
#include <unistd.h>
#include <sys/uio.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <arpa/inet.h>
#include <sys/time.h>
#endif
#include <string.h>

#include <iostream>

using namespace sockets;

J_Recibir::J_Recibir( void )
{
    _port = 0;
    _initialized = false;
    _buffer = 0L;
}

J_Recibir::~J_Recibir( void )
{
#if defined (WIN32) && !defined(__CYGWIN__)
    closesocket( _so);
#else
    close( _so );
#endif
}

bool J_Recibir::init( void )
{
#if defined(WIN32) && !defined(__CYGWIN__)
    WORD version = MAKEWORD(1,1);
    WSADATA wsaData;
    // First, we start up Winsock
    WSAStartup(version, &wsaData);
#endif

    if( _port == 0 )
    {
    fprintf( stderr, "Receiver::init() - port not definedn" );
    return false;
    }

    if( (_so = socket( AF_INET, SOCK_DGRAM, 0 )) < 0 )
    {
        perror( "Socket" );
    return false;
    }



    /*int buffsize  = 50000;
    setsockopt( _so, SOL_SOCKET, SO_RCVBUF, (const char*)&buffsize, sizeof(buffsize));*/

#if defined (WIN32) && !defined(__CYGWIN__)
//    const BOOL on = TRUE;
//    setsockopt( _so, SOL_SOCKET, SO_REUSEADDR, (const char*) &on, sizeof(int));
#else
    int on = 1;
    setsockopt( _so, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
#endif




//    struct sockaddr_in saddr;
    saddr.sin_family = AF_INET;
    saddr.sin_port   = htons( _port );
#if defined (WIN32) && !defined(__CYGWIN__)
    saddr.sin_addr.s_addr =  htonl(INADDR_ANY);
#else
    saddr.sin_addr.s_addr =  0;
#endif

    if( bind( _so, (struct sockaddr *)&saddr, sizeof( saddr )) < 0 )
    {
        perror( "bind" );
        return false;
    }

    u_long iMode = 1;       // 1 para No bloqueante, 0 para bloqueante
    ioctlsocket(_so, FIONBIO, &iMode);

    _initialized = true;
    return _initialized;
}


void J_Recibir::setPort( const short port )
{
    _port = port;
}

void J_Recibir::setBuffer( void *buffer, const unsigned int size )
{
    _buffer = buffer;
    _buffer_size = size;
}

int J_Recibir::sync( void )
{
    if(!_initialized) init();

    if( _buffer == 0L )
    {
        fprintf( stderr, "Receiver::sync() - No buffern" );
        return -1;
    }

#if defined(__linux) || defined(__FreeBSD__) || defined( __APPLE__ )
    socklen_t 
#else
    int
#endif
        size = sizeof( struct sockaddr_in );

    fd_set fdset;
    FD_ZERO( &fdset );
    FD_SET( _so, &fdset );

    struct timeval tv;
    tv.tv_sec = 0;
    tv.tv_usec = 0;

#if defined (WIN32) && !defined(__CYGWIN__)
//    saddr.sin_port   = htons( _port );
    recvfrom( _so, (char *)_buffer, _buffer_size, 0, (sockaddr*)&saddr, &size );


//    recvfrom(sock_Receive, szMessage, 256, 0, (sockaddr*)&addr_Cli, &clilen)
    int err = WSAGetLastError ();
    if (err!=0){
        fprintf( stderr, "Receiver::sync() - error %dn",err );
        perror("Error: ");
    }

    while( select( _so+1, &fdset, 0L, 0L, &tv ) )
    {
        if( FD_ISSET( _so, &fdset ) )
        {
            recvfrom( _so, (char *)_buffer, _buffer_size, 0, (sockaddr*)&saddr, &size );
        }
    }
#else
    recvfrom( _so, (caddr_t)_buffer, _buffer_size, 0, 0, &size );
    while( select( _so+1, &fdset, 0L, 0L, &tv ) )
    {
        if( FD_ISSET( _so, &fdset ) )
        {
            recvfrom( _so, (caddr_t)_buffer, _buffer_size, 0, 0, &size );
        }
    }
#endif

    if (err!=0) return -1;
    else        return 0;
}

И вот как я вызываю функцию приема:

     sockets::J_Receiver receiverGUI = new sockets::J_Recibir();
     receiverGUI->setPort(4020);
     nDatosGUI = 1404;
     float* datosGUI = new datosGUI[nDatosGUI ];
     receiverGUI->setBuffer((void *)datosGUI, sizeof(float)*nDatosGUI);

Обновлено 28.11.2020

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Pyatilistnik.org. В прошлый раз мы с вами разобрали возможности утилиты PING, рассмотрели как ее применять на практике. В сегодняшней публикации я вам покажу, как устраняется боль и печаль в операционных системах Windows, я говорю про длинные пути, в своей практике я очень часто встречал жалобы «Слишком длинный целевой путь» или «Слишком длинный конечный путь«, то же самое вы можете встретить и при удалении. Ниже я покажу, как выкручиваться из данной ситуации.

Описание проблемы длинных путей

Раньше имена файлов в Windows ограничивались форматом 8.3 — всего восемь символов для имени файла и три для расширения. С появлением Windows 95 Microsoft сняла этот предел и позволила использовать гораздо более длинные имена.

Тем не менее, файловая система Windows по-прежнему накладывает некоторые ограничения, например, какие символы могут использоваться в именах файлов и общую длину путей. Некоторое время максимальная длина пути составляла 260 символов, но с появлением Windows 10, часть ограничений начала потихоньку уходить, например для приложений и появилась возможность отключить проверку MAX_PATH и использовать длинные пути без префикса \?.

Что интересно, значение в 260 символов обусловлено значением MAX_PATH Win32 API. У файловой системы NTFS максимальная длина пути ″немного″ больше и составляет  32767 символа. Для обхода ограничений Win32 API некоторые приложения используют формат UNC, указывая абсолютный путь с префиксом \?, например так:

Большинство людей может и не столкнуться с ней, а вот почти каждый системный администратор обязательно это увидит. Тут все дело в том, что в большинстве организаций есть свои сетевые файловые ресурсы, через которые пользователи производят обмен и работу с документами. В какой-то момент люди могут создать такой путь, который будет 258 или 260 символов, попытаются туда скопировать файл, а им выдастся ошибка:

Тоже самое при копировании в папку, так же выскакивает «Слишком длинный целевой путь».

Вот ошибка при извлечении архива в сетевую папку:

Методы снимающие ограничения на длину пути в Windows

• Через групповую или локальную политику Windows (Применимо только к Windows 10 и Windows Server 2016 и выше)
• Через реестр Windows (Применимо только к Windows 10 и Windows Server 2016 и выше)
• Через сторонние утилиты 7-Zip, Far, TotalCommander (Применимо ко всем версиям Windows)
• Использование силинков (символических ссылок) (Применимо ко всем версиям Windows)
• Через сетевой диск, для укорачивания пути
• Утилиты xcopy, robocopy

Нюансы длинных путей в приложениях

Есть один нюанс. Этот новый параметр (имеется ввиду та политика и ключ реестра) не обязательно будет работать со всеми существующими приложениями, но он будет работать с большинством. В частности, любые современные приложения должны работать нормально, как и все 64-битные приложения. Старые 32-разрядные приложения должны быть применимы для работы, что на самом деле просто означает, что разработчик указал в файле манифеста приложения, что приложение поддерживает более длинные пути. Большинство популярных 32-битных приложений не должно вызывать проблем. Тем не менее, вы ничем не рискуете, пробуя настройку. Если приложение не работает, единственное, что произойдет, это то, что оно не сможет открывать или сохранять файлы, сохраненные в местах, где полный путь превышает 260 символов.

Если вы разработчик, то чтобы ваше приложение имело возможность работать с длинными путями Windows, в манифесте обязательно указывайте следующие настройки:

Как в Windows 10 отключить ограничение на длину пути в 260 символов через политику

Чем примечателен данный метод, так это тем, что неподготовленных пользователей он не вынуждает выполнять команды или производить правку реестра, тут все в графическом виде. Так же если у вас есть домен Active Directory и вы хотите массово убрать ошибки «Слишком длинный целевой путь» или «Слишком длинный конечный путь» в приложениях и запретить им проверять MAX_PATH и использовать длинные пути без префикса \?, то групповые политики вам это помогут.

Покажу для начала, как делать через локальную политику, открываете окно «Выполнить» в котором пишите gpedit.msc.

Далее идем по пути:

Найдите тут параметр «Включить длинные пути Win32 (Enable Win32 long paths)«, по умолчанию он отключен, и я честно не понимаю почему. Активируйте его.

Как я писал выше, в проводнике это не даст ни каких эффектов, поэтому вы все так же будите получать ошибку при копировании, создании, удалении «Слишком длинный целевой путь» или «Слишком длинный конечный путь«. Ниже я покажу, что делать если нужно что-то там удалить или изменить. Данное ограничение в длине пути теперь не подхватиться на лету всеми приложениями, потребуется перезагрузка.

Включение поддержки длинных путей через реестр

Данный метод ни чуть не сложнее предыдущего и делает все то же самое, включает поддержку длинных путей свыше 256 символов для приложений Windows. Когда вы что-то меняете через редактор политик, по сути меняются настройки в реестре, это нужно помнить и знать. Сейчас я вам покажу какой ключ меняется. Откройте редактор реестра Windows.  Перейдите в раздел:

тут вам необходимо найти параметр LongPathEnabled, которому для активации поддержки длинных путей и изменения ограничений в MAX_PATH, нужно задать значение «1». Тут потребуется перезагрузка.

Все что вам нужно, это распаковать zip-архив и запустить нужный файл активации, потом так же перезагрузиться, так как у вас будет создан нужный ключ реестра, без необходимости лезть в реестр самостоятельно.

Еще вы можете сделать такую поддержку и для конкретного пользователя по пути:

Если там нет ключа LongPathsEnabled, то создайте его, тип DWORD (32 бита) и значение 1.

Как в Windows 10 отключить ограничение на длину пути в 260 символов через PowerShell

Не все люди готовы копаться в редакторах и реестрах, им нужно быстрое решение, одним из таких является PowerShell. В оболочке выполните команду для активации параметра «Включить длинные пути Win32 (LongPathEnabled)». Не забываем перезагрузить систему.

Как удалять, копировать, переносить файлы и папки при ошибке с длинными путями

Разобравшись с тем, как отключить проверку MAX_PATH в приложениях, давайте теперь поймем и научимся решать проблему длинных путей на файловых шарах и просто в проводнике. Классическая ситуация, когда пользователь попытался перенести свой файл или удалить его, создать папку и так далее, и он получает ошибку с пресловутыми длинными путями. Он просит разобраться вас и тут начинаются танцы с бубнами, вы просите его либо переименовать часть пути, или попросить его произвести действия в другом расположении, или просто забить, сказав, что виновата Windows со своими ограничениями, но мы же с вами профессионалы и инженеры, поэтому должны уметь выходить из таких ситуаций.

Как в Windows 10 отключить ограничение на длину пути в 260 символов через командную строку

Запустите командную строку в режиме администратора и введите:

Потребуется перезагрузка.

Обход ограничений длинных путей через 7zFM

Наверняка многие знают архиватор 7Zip, но мало кто пользуется его файловым менеджером 7zFM.exe, а зря именно он может вам помочь в ситуации с сообщением «Слишком длинный целевой путь» или «Слишком длинный конечный путь».  Вот у меня есть тестовая директория, у которой уже есть 260 символов в пути, и я не могу там создавать новую папку.

Откройте 7zFM.exe и перейдите в нем в конечную папку вашего пути.

Для создания новой папки нажмите клавишу F7.

Задайте необходимое вам имя, в моем примере это будет «БОльше 260 Microsot«.

В результате у нас создалась новая папка и заметьте 7zFM не ругнулся на наличие длинных путей, он их игнорирует просто и все.

Проверяем, что директория доступна через проводник Windows.

Все прекрасно отображается. Теперь я думаю вы легко сможете переносить, копировать, удалять файлы через 7zFM, когда вам проводник Windows ругается на наличие длинных путей.

Как обойти ограничение длинных путей через символьную ссылку

Такой трюк мы с вами уже проделывали, когда нужно было переносить IMAP профиль у Outlook. Смысл в том, что создается файл в нужном вам месте, и этот файл это просто ярлык ссылающийся на нужный вам файл или папку, после этого путь сокращается и вы можете удалять или создавать все что вам нужно. Откройте командную строку, далее вам нужно иметь два составляющих:

• Путь где будет лежать файл символической ссылки — в моем примере C:короткий путь
• Длинный путь — C:ShareWINDOW~1C73D~1C6BF~1 D915~15C04~1B4E5~1260MIC~1

Нам поможет команда mklink, где ключ /D создает ссылку на каталог

Символическая ссылка успешно создана, можно проверять.

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

Как обойти ограничение длинных путей через сопоставление subst

subst — простая команда позволяющая связать нужный путь к каталогу с буквой диска. Так же откройте командную строку в режиме администратора и сопоставьте ваш длинный путь с буквой W.

У вас в проводнике Windows должен появиться диск с данной буквой, если его нет, то прочитайте статью «Не появляется диск после команды subst» или просто в проводнике вбейте W: и нажмите Enter.

Как обойти ограничение длинных путей через монтирование сетевого диска

В командной строке используйте команду net use, далее буква диска, которую мы присваиваем и в самом конце путь:

Как видим все прекрасно отработало и диск появился.

Использование утилит Far или Total Commander

После включения параметра «Включить длинные пути Win32» данные утилиты в 100% случаев помог вам произвести любые действия с папками или файлами на любом длинном пути в системе Windows. Откройте Total Commander и создайте для примера папку в каталоге с длинным путем, напоминаю для этого нужно нажать F7.

Как видите все прекрасно создается, удаляется или копируется при желании.

Как еще обойти проблему с длинными путями Windows

В мир виртуализации и облаков, многие компании переносят свои файловые ресурсы именно туда. Например в моей компании используют для хранения большинства данных это Google Drive, кто-то диски mail.ru или Яндекса, не нужно этого бояться, главное смотрите, чтобы это подходило с юридической точки зрения но и не нужно лукавить это может стоить дополнительных расходов, но зато ни каких длинных путей, вышедших из строя дисков в RAID, место наращивается на лету, короче одни плюсы.

На этом у меня все, мы разобрали как исправляются ошибки «Слишком длинный целевой путь» или «Слишком длинный конечный путь«, с вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Sometimes I get incredibly long errors in my code that I don’t understand so I just rework my code to avoid whatever was causing the error. I had another one today that I simply can’t avoid.

My code:

#include <iostream>
#include <fstream>
#include <string>
#include <cctype>
#include <vector>

using namespace std;

void readFile(string);

class info {
    public:

    int rows;
    int cols;
    vector < string > data;
};

int main(int argc, char **argv){

    string filename1;
    filename = argv[1];
    readFile(filename);

    return 0;
}

//should read onle line at a time from a file and print it
void readFile(string filename1){
    fstream datafile;
    datafile.open(filename1);

    while (!datafile.eof()){
            string line;
            getline(datafile,line);
            cout<<line<<endl;
    }

    datafile.close();
}

The error stems from trying to get the name of the file from argv[1]. It was working fine when I just gave it the file name.

The error:

project2.cpp: In function ‘int main(int, char**)’:
project2.cpp:22:2: error: ‘filename’ was not declared in this scope
  filename = argv[1];
  ^
project2.cpp: In function ‘void readFile(std::string)’:
project2.cpp:32:25: error: no matching function for call to     ‘std::basic_fstream<char>::open(std::string&)’
  datafile.open(filename1);
                     ^
project2.cpp:32:25: note: candidate is:
In file included from project2.cpp:2:0:
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/include/c++/fstream:889:7: note: void     std::basic_fstream<_CharT, _Traits>::open(const char*, std::ios_base::openmode)     [with _CharT = char; _Traits = std::char_traits<char>; std::ios_base::openmode =     std::_Ios_Openmode]
       open(const char* __s,
       ^
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/include/c++/fstream:889:7: note:   no     known conversion for argument 1 from ‘std::string {aka std::basic_string<char>}’     to ‘const char*’

I am using Cygwin. I used it last semester as well when I was writing code in C, and my professor had us check certain installation options at the time. Could these installation options be the root of the problem? Or are errors like this common in C++? Thanks.

ChatGPT — это мощная языковая модель, которая генерирует ответы на инструкции на человеческом языке после обучения на большом количестве данных. С самого начала он оказал огромное влияние на своих пользователей. Он использовался в различных приложениях, таких как чат-боты, обслуживание клиентов, языковой перевод и создание контента. Однако при создании длинных ответов могут возникать сетевые ошибки, препятствующие завершению ответа ChatGPT, что может нарушить работу пользователя, рабочий процесс и производительность.

Сетевые ошибки могут помешать пользователю получить ответ или он может получить неполный или неполный ответ. Это может быть неудобно для пользователей, которые полагаются на ChatGPT для создания длинных ответов в своей повседневной работе или других задачах. Если вы также полагаетесь на ChatGPT в своей повседневной работе и постоянно получаете эту ошибку, не беспокойтесь! Вы можете попробовать несколько быстрых и простых способов решить эти проблемы! что уменьшит влияние и поможет вам продолжать получать длинные ответы ChatGPT. Итак, приступим.

ChatGPT — это сложная языковая модель, генерирующая ответы с использованием большого количества вычислительных ресурсов. В результате иногда могут возникать сетевые ошибки, особенно при генерации длинных ответов. Может быть несколько причин, по которым ChatGPT продолжает испытывать сетевые ошибки, в том числе:

• Если сервер обрабатывает много запросов одновременно, это может замедлить работу и вызвать сетевые ошибки.
• Плохое подключение к Интернету может вызвать сетевые ошибки при обмене данными с сервером, на котором размещен ChatGPT.
• Если ответ ChatGPT слишком велик, это может вызвать сетевые ошибки, особенно если он усечен или обрезан.
• Если значение времени ожидания запроса слишком мало, у сервера может не хватить времени для обработки запроса, что приведет к сетевым ошибкам.
• Сетевые ошибки также могут быть вызваны техническими проблемами в системе, такими как ошибки или сбои.

Способы исправления сетевой ошибки ChatGPT при длинных ответах

Если у вас возникают сетевые ошибки при использовании ChatGPT, особенно при создании длинных ответов, вы можете попробовать следующие исправления:

1. Проверьте, не работает ли ChatGPT.

Проверка того, не работает ли ChatGPT, может помочь выяснить, вызваны ли сетевые ошибки проблемами с сервером ChatGPT. Если ChatGPT не работает, все запросы к серверу завершатся неудачно, и пользователи не смогут генерировать длинные ответы. В этом случае пользователям следует повторить попытку позже или дождаться восстановления службы.

Вы можете проверить Страница состояния службы чтобы узнать, не работает ли ChatGPT или возникают какие-либо проблемы. Многие платформы и службы с поддержкой ChatGPT имеют страницу состояния службы, на которой отображается текущий статус службы, включая любые известные проблемы или перебои в работе службы. Проверяя страницу состояния службы, пользователи могут быстро определить, вызваны ли сетевые ошибки, с которыми они сталкиваются, перебоями в обслуживании или другими факторами.

2. Проверьте подключение к Интернету

Когда подключение к Интернету нестабильное, медленное, потеря пакетов или большая задержка, могут возникнуть сетевые ошибки. При генерации длинных ответов с помощью ChatGPT эти проблемы могут прервать связь между клиентом и сервером, что приведет к сетевым ошибкам. Пользователи могут предпринять несколько шагов для улучшения своего интернет-соединения, в том числе:

• Перезагружаем роутер: Перезапуск маршрутизатора может помочь удалить любые кэшированные данные и сбросить соединение, что может помочь устранить сетевые ошибки.
• Подключение к другой сети: Пользователи могут попробовать подключиться к другой сети, например к мобильной точке доступа или другой сети Wi-Fi, чтобы проверить, сохраняется ли проблема.
• Обновление интернет-плана: Для ChatGPT требуется скорость соединения не менее 5 Мбит/с. Если скорость интернета постоянно низкая или нестабильная, пользователям следует перейти на тарифный план с более высокой скоростью, чтобы обеспечить надежное и стабильное соединение.
• Устранение неполадок в настройках роутера: Пользователи могут попробовать устранить неполадки в настройках маршрутизатора, например отключить параметры QoS или брандмауэра, которые могут мешать соединению.

Проверка подключения к Интернету важна для устранения сетевых ошибок и обеспечения бесперебойной работы ChatGPT. Выполняя эти шаги, пользователи могут устранить проблемы с сетью при создании длинных ответов с помощью ChatGPT и обеспечить надежное и стабильное соединение для будущего использования.

3. Перезагрузите или снова откройте веб-браузер.

Перезагрузка веб-страницы ChatGPT — лучшее решение для устранения проблемы с сетевой ошибкой в ​​ChatGPT. Обновление страницы перезагрузит все сервисы ChatGPT и запустит веб-страницу заново. Большинство проблем с ChatGPT можно решить простой перезагрузкой страницы. Перезагрузка веб-страницы может быть полезна для обновления содержимого страницы, проверки новой информации или изменений или исправления ошибок или проблем, которые могли возникнуть во время первоначальной загрузки страницы.

Повторное открытие веб-браузера может быть простым и быстрым решением некоторых сетевых ошибок ChatGPT, например, возникающих при генерации длинных ответов. Интернет-браузер мог обнаружить ошибку, которая мешает обмену данными между клиентом и сервером. Пользователи могут просто закрыть окно браузера, а затем снова открыть его, чтобы снова открыть веб-браузер.

4. Очистите кеш браузера

Очистка кэшированных данных иногда может помочь исправить сетевые ошибки ChatGPT при генерации длинных ответов. Очистка кэшированных данных иногда может помочь исправить сетевые ошибки ChatGPT при генерации длинных ответов. Кэш браузера хранит временные данные с веб-сайтов, такие как изображения, тексты и другие ресурсы, которые со временем могут быть повреждены или устаревшими. Это может вызвать проблемы со связью между клиентом и сервером, что приведет к сетевым ошибкам при создании длинных ответов с помощью ChatGPT.

Чтобы очистить кеш и файлы cookie в Google Chrome, выполните следующие действия:

1. Выберите меню из трех точек в правом верхнем углу окна браузера.
2. Выбирать «Дополнительные инструменты» а потом «Очистить данные просмотра».
   
3. Выбирать «Все время» из «Временной диапазон», чтобы очистить все сохраненные данные.
4. Выбирать «Файлы cookie и другие данные сайта» и «Кэшированные изображения и файлы” из выпадающих меню.
5. Чтобы удалить сохраненные данные из браузера, нажмите «Очистить данные.»
   
   

Очистка кеша браузера может также привести к удалению сохраненной информации для входа, настроек веб-сайта и других данных, поэтому перед очисткой кеша следует знать о возможных последствиях.

5. Выйдите из ChatGPT

В некоторых случаях может помочь выход из системы и повторный вход в ChatGPT, особенно если проблема связана с текущим сеансом или учетной записью пользователя. Пользователь может начать новую сессию с сервером, выйдя из системы и снова войдя, что может помочь решить любые временные проблемы с сессией.

Вот как вы можете это сделать.

1. Нажмите «Выйти” в интерфейсе ChatGPT.
   
2. Закройте браузер и подождите несколько минут.
3. Перезапустите веб-браузер и перейдите на сайт ChatGPT.
4. Войдите в свою учетную запись и попробуйте еще раз создать длинные ответы.
   

Если выход и повторный вход не устраняет сетевые ошибки при создании длинных ответов, вы можете попробовать другие методы устранения неполадок, упомянутые ниже.

6. Используйте другой веб-браузер

Использование другого веб-браузера может быть полезным методом устранения неполадок при получении сетевых ошибок с помощью ChatGPT при длинных ответах. Сетевые ошибки иногда вызваны проблемами с текущим браузером, такими как устаревшие версии, поврежденный кеш или расширения, или сбои. Пользователи могут предотвратить это, переключившись на другой веб-браузер и установив новое соединение с сервером ChatGPT.

Чтобы использовать другой веб-браузер с ChatGPT, вы можете закрыть текущий интернет-браузер, загрузить и установить другой веб-браузер, например Chrome, Firefox, Safari или Edge. Затем,

1. Откройте новый веб-браузер.
2. Перейдите на сайт ChatGPT.
3. После этого войдите в учетную запись, чтобы попробовать генерировать длинные ответы.
   

Войдите в систему и проверьте наличие длинного ответа. Если проблема не устранена, попробуйте другие способы устранения неполадок, упомянутые ниже.

7. Отключите VPN

Отключение VPN может помочь в устранении сетевых ошибок при создании длинных ответов с помощью ChatGPT. VPN (виртуальные частные сети) могут иногда прерывать связь между пользователем и сервером, что приводит к сетевым ошибкам и снижению производительности.

Следуйте инструкциям, чтобы отключить VPN:

• Найдите VPN на рабочем столе или в веб-браузере.
• Отключите программное обеспечение VPN.
• Retry генерирует длинные ответы в ChatGPT.

Если VPN вызывает сетевые ошибки, его отключение может помочь восстановить соединение и повысить производительность ChatGPT. Однако важно помнить, что отключение VPN может поставить под угрозу конфиденциальность и безопасность интернет-соединения пользователя. В результате пользователи должны отключать VPN только в том случае, если они согласны с возможными рисками и не имеют другого выбора.

8. Избегайте периодов интенсивного движения

Избегание периодов высокой нагрузки может помочь свести к минимуму возникновение сетевых ошибок при создании длинных ответов с помощью ChatGPT. В часы пиковой нагрузки, например, в рабочее время или вечером, когда много пользователей активно, серверы могут быть перегружены, что приводит к медленному времени отклика и сетевым ошибкам. Избегая времени с высоким трафиком, пользователи могут столкнуться с более быстрым временем отклика и очень небольшим количеством сетевых ошибок при создании длинных ответов с помощью ChatGPT.

9. Запрашивайте меньше информации за раз у ChatGPT

Запрос меньшего количества сведений от ChatGPT за раз может помочь в устранении сетевых ошибок при создании длинных ответов. Объем информации, передаваемой по сети при генерации длинных ответов, может создать нагрузку на ресурсы сервера, вызывая задержки или ошибки при обработке запросов.

Пользователи могут попробовать ограничить длину вводимого текста или количество запрашиваемых ответов, чтобы запрашивать меньше информации за раз. Пользователи, например, могут запросить 10 ответов по 100 слов каждый вместо одного ответа на 1000 слов.

10. Обратитесь в службу поддержки OpenAI

Если ни один из вышеупомянутых шагов по устранению неполадок не работает, обращение в службу поддержки OpenAI может быть лучшим вариантом для устранения сетевых ошибок при создании длинных ответов с помощью ChatGPT. У OpenAI есть специальная группа поддержки, которая может помочь пользователям с техническими проблемами, такими как сетевые ошибки и другие ошибки, возникающие при использовании ChatGPT.

Вы можете связаться Поддержка OpenAI посетив веб-сайт OpenAI и перейдя на страницу поддержки. Затем вы можете отправить запрос в службу поддержки или связаться со службой поддержки по телефону или электронной почте. При обращении в службу поддержки OpenAI вы должны предоставить как можно больше информации о проблеме, включая любые полученные сообщения об ошибках, действия, предпринятые для воспроизведения ошибки, и любые предпринятые действия по устранению неполадок. Это может помочь группе поддержки определить основную причину проблемы и оказать более эффективную помощь.

Заключительные слова

Получение сетевых ошибок при генерации длинных ответов с помощью ChatGPT может сильно расстраивать и негативно влиять на работу пользователей. Но только следуя шагам, упомянутым выше, вы сможете уменьшить влияние сетевых ошибок и получить более приятный опыт использования ChatGPT.

Мы искренне считаем, что данные, представленные в разделе этой статьи под названием «Как исправить сетевую ошибку ChatGPT при длинных ответах», были полезны. Мы искренне надеемся, что это руководство поможет вам решить вашу проблему. Если у вас есть какие-либо вопросы или предложения, пожалуйста, оставьте их в разделе комментариев ниже.

Если у вас есть мысли о Как исправить сетевую ошибку ChatGPT при длинных ответах?то не стесняйтесь заглянуть ниже поле для комментариев.

Запустите ошибку:

Error running ‘CmsFrontApplication’: Command line is too long. Shorten command line for CmsFrontApplication or also for Spring Boot default configuration.

Решение

Причина анализа

Прямая причина этой проблемы заключается в том, что когда идея интегрированная среда разработки запускает ваш «исходный код» (обратите внимание, что она работает на основе исходного кода, а не хороший пакет JAR), он проходит через команду (первый банк очень долго) Начните процесс Java. Эта команда в основном содержит две основные части:

1. VM -программапараметр. Это параметры -xx -d и другие параметры, которые вы видите.
2. -classpathПараметры, он используется для указания пути пакета JAR во время работы (поскольку пакет JAR теоретически может быть доступен в любом месте), эта часть более вероятно

Ключ заключается в-classpathпараметр,Это может быть очень долгоЧем дольше вы полагаетесь на упаковку JAR, тем дольше этот путь; чем дольше ваш базовый путь, тем дольше он; если вы также проведете сложный тест на юнит, тем больше длины будет дольше, тем дольше может быть длина Ой. В целом: эта частьВероятноСупер долго и ведущий кCommand line is too longЯвление.

Если путь класса слишком длинный (возможность), или у вас есть много параметров виртуальной машины (менее вероятно), программа не может быть запущена. Причина в томБольшая часть операционной системыЕсть ограничение длины командной строки. В этом случае Intellij Idea обеспечит возможность попытаться сократить путь.

---

Идея старая версия программа

Для этой проблемы, в предыдущей версии (именно в версии 2017.3) вам необходимо решить ее через конфигурацию файла XML: Найдите в рамках проекта.idea/workspace.xmlЭтот файл добавлен следующим образом:

<component name="PropertiesComponent">
    ...
    <!-Это предложение-это элемент, который вам нужно добавить->
    <property name="dynamic.classpath" value="true" />
    ...
</component>

Начните программу, чтобы снова найти решение проблем. У меня есть основания полагать, что никто не должен использовать такую ​​старую версию в настоящее время, но большинство статей, которые вы искали в Интернете, все еще остаются этим решением, поэтому, пожалуйста, обратите внимание (версия 2017.3, обратитесь к решению ниже).

Любая не определенная версия решений и статей анализа источников не несет ответственности. Как программист, вы должны правильно улучшить сознание своей версии

---

Идея схема новой версии: командная строка короче

В идее2017.3В версии представлена ​​новая функция: командная строка короче. Он предназначен для решения таких проблем, то естьИз этой версииБольше не нужно редактировать настройки IDE через XML -файл. Вместо этого он может работать непосредственно на интерфейсе:

Изначально Idea Intellij пыталась написать длинный путьТекстовый файл(Это означает, что приложение является промежуточным погрузчиком). Но, к сожалению, это не подходит для определенных рамок, таких как Jmock. Затем Intellij Idea пытается использовать более или менее стандартные методы, и длинный путь будет упакован вclasspath.jarсередина. К сожалению, это не работает для других рамок.

Резюме: Обе эти схемы не являются 100%совершенством.

Из предыдущего диалогового окна вы можете видеть, что идея предоставляет в общей сложности три шортера командной строки для выбора:

1. Никто. Это опция по умолчанию. IDE не сокращает длинный путь. Если командная строка превышает предел операционной системы,Тогда идея не сможет запустить ваше приложение
2. JAR Manifest. IDE прошелВременный классПеренести длинные пути. Примитивный путьMANIFEST.MFОпределение как атрибут пути в classpath.jar
3. Файл ClassPath. IDE будет писать длинные пути в текстовые файлы

---

JAR MANIFEST Метод

Выберите этот метод, запустите тестовую программу, первая строкаВесь контентДисплей следующим образом:

D:developerjdks1.8.0_241binjava.exe -XX:TieredStopAtLevel=1 -noverify 
    -Dspring.output.ansi.enabled=always -Dcom.sun.management.jmxremote 
    -Dspring.jmx.enabled=true -Dspring.liveBeansView.mbeanDomain 
    -Dspring.application.admin.enabled=true 
    "-javaagent:C:Program FilesJetBrainsIntelliJ IDEA 2020.1.1libidea_rt.jar=5975:C:Program FilesJetBrainsIntelliJ IDEA 2020.1.1bin" -Dfile.encoding=UTF-8 
    -classpath C:UsersxxxAppDataLocalTempclasspath1199511058.jar 
    com.xxx.Application

Разница в основном-classpathВ этой линии он больше не показывает путь всех JAR, а «упакован» в файл JAR.Длина командыЗначительное сокращение, на 100%гарантия не будет очень длинной, поэтому вы не сообщите об ошибке.

Кроме того, в этой идее вы можете щелкнуть по этому пути JAR по содержанию докладчика (действительно интимный):

Конечно, вы также можете найти этот файл JAR на своем диске, а затем просмотреть его (объяснение: Пожалуйста, убедитесьУдерживайте стартовую веткуПерейдите, чтобы найти соответствующий файл, в противном случае временный файл будет удален после окончания потока):

С особым акцентом на: Во время практики я использовал этот метод, в котором сумка для JAR не была загружена. Напомните вам здесь, что если у вас также есть аналогичные явления, пожалуйста, переключитесь на использование метода файла ClassPath.

В конце концов, чиновник также сказал: эти два пути сокращены, что может быть несовместимо с определенными рамками, просто

---

Метод файла ClassPath

Выберите этот метод, запустите тестовую программу, первая строкаВесь контентДисплей следующим образом:

D:developerjdks1.8.0_241binjava.exe -XX:TieredStopAtLevel=1 -noverify 
    -Dspring.output.ansi.enabled=always -Dcom.sun.management.jmxremote 
    -Dspring.jmx.enabled=true -Dspring.liveBeansView.mbeanDomain 
    -Dspring.application.admin.enabled=true 
    "-javaagent:C:Program FilesJetBrainsIntelliJ IDEA 2020.1.1libidea_rt.jar=5975:C:Program FilesJetBrainsIntelliJ IDEA 2020.1.1bin" -Dfile.encoding=UTF-8 
    -classpath C:UsersxxxAppDataLocalTempidea_classpath921151059
    com.xxx.Application

---

---

Расширенные знания: максимальная длина команды системы Windows

Это знание расширения, расширяющее контент для чтения.

Теперь, когда причина этой проблемы заключается в том, что порядок в том, что порядок очень длинный и «сообщил об ошибке», брат подумайте об этомСколько символов самая длинная команда Windows?Пересечение С этим вопросом я начал выяснять и, наконец, нашел ответ, который я хотел на официальном сайте Windows. Адрес здесь:https://docs.microsoft.com/zh-cn/windows/win32/api/processenv/nf-processenv-setenvironmentvariablea?redirectedfrom=MSDN

В окнах длина командной строки — максимальная длина32767Символ (разница между длиной оболочки, длина командной строки). При предоставлении большого шкалевого пути он нарушает этот предел, и Windows отказывается выполнять команду и бросить код ошибки 87. Рекомендуемые решения следующие: следующее:

1. Скопируйте всю банку в публичную папку, напримерc:jars, Затем включите его. Таким образом, в каждой банке есть однаКороткий путь,Прямо сейчасc:jars(Не длинный путьc:program filesapplibapp-jar1.jar) И должен иметь возможность контролировать этот путь в пределах 38 КБ
2. Если шаг 1 не работает, вы можете извлечь одну банку в папку и создатьНовая банкаСущность Это должно только представить эту новую банку

Это две идеи решения задач: пути коротких целей (простые и эффективные) и методы упаковки (100%может решить проблему)

---

Мыслительные вопросы

1. Для МаоПриложение Spring BootНе беспокойтесь об ошибке командной строки слишком длинная в производственной среде?
2. какаяЭффективный способМожете ли вы избежать этой проблемы в вашей среде разработки?