انتقال داده ها به ابتکار طرف گیرنده قطع شد. علل کار نادرست امضای الکترونیکی و راه های رفع مشکلات

بسیاری از شرکت کنندگان در تدارکات، صرف نظر از تجربه، با مشکل کار صحیح در بستر تجارت الکترونیکی مواجه هستند. این خطاها را می توان در هر زمان از جمله در طول فرآیند تجارت الکترونیکی کشف کرد.

عواقب آن می تواند بسیار متفاوت باشد، یعنی:

• درخواست به موقع برای شرکت در مسابقه ارسال نشده است
• مزایده الکترونیکی گم شده
• قرارداد دولتی به موقع امضا نشده است

سه مشکل رایج در کار با امضای الکترونیکی

1. گواهی شرکت کننده در تدارکات در بستر الکترونیکی نمایش داده نمی شود
2. امضای الکترونیکی اسناد را امضا نمی کند

در واقع، ممکن است خطاهای بسیار بیشتری وجود داشته باشد، اما ما دلایل اصلی و آنها را تجزیه و تحلیل خواهیم کرد، و همچنین راه های ممکن برای رفع مشکلات را بیان می کنیم.

مهم‌ترین نکته این است که به خاطر داشته باشید برای اینکه امضای الکترونیکی به درستی کار کند، باید حداقل از اینترنت اکسپلورر نسخه 8 و ترجیحاً بالاتر از 11 استفاده نکنید (در نسخه 11 هیچ تضمینی وجود ندارد که امضای پایدار کار کند).

هنگام تلاش برای ورود به سیستم، گواهی کلید امضا در سایت قابل مشاهده نیست

در این مورد، خطا به دلایل مختلف به طور همزمان ایجاد می شود، یعنی:

• پیکربندی اشتباه گواهی کلید امضا
• مرورگر اینترنت به درستی پیکربندی نشده است
• گواهی ریشه مرجع صدور گواهی مفقود شده است

چگونه یک مشکل را حل کنیم؟

اول از همه، باید مطمئن شوید که قسمت عمومی گواهی را به درستی از طریق CIPF (Crypto Pro) در قسمت شخصی نصب کرده اید. در این صورت نسخه برنامه نصب شده با نوع سیستم عامل شما مناسب است.

سپس در تنظیمات مرورگر اینترنت اکسپلورر، باید آدرس سایت را به سایت های قابل اعتماد اضافه کنید و تمام کنترل های ActiveX را فعال کنید.

امضای الکترونیکی هنگام امضای اسناد خطا می دهد

به طور معمول، این خطا در تعدادی از موارد رخ می دهد:

• مجوز CryptoPro منقضی شده است
• رسانه با گواهی متفاوت درج شده است

چطوری میشه اینو تعمیر کرد؟

برای انجام این کار، باید با تماس با مرجع صدور گواهینامه، مجوز جدیدی دریافت کنید. پس از اینکه مجوز با موفقیت به دست آمد، باید CryptoPro را راه اندازی کنید و شماره سریال مجوز را وارد کنید.

در مورد دوم، شما باید تمام ظروف (حامل) دربسته وارد شده در پورت USB کامپیوتر را بررسی کنید و بررسی کنید که گواهی صحیح انتخاب شده است.

سیستم هنگام ورود به پلت فرم الکترونیکی خطا می دهد

این خطا می تواند ناشی از ترکیبی از دلایل ذکر شده در بالا باشد. همانطور که تمرین نشان می دهد، چنین خطایی در درجه اول به دلیل نصب نادرست کتابخانه Capicom ظاهر می شود. توصیه می کنیم هنگام استفاده از سیستم 64 بیتی، وجود کتابخانه نصب شده را بر روی رایانه خود بررسی کنید و به لزوم کپی کردن 2 فایل سیستم با پسوند dll در یکی از پوشه های ویندوز توجه کنید.

برای جلوگیری از چنین اشتباهاتی، قبل از نصب امضای الکترونیکی، نصب و پیکربندی امضای الکترونیکی را مطالعه کنید و یا سفارش صدور و پیکربندی امضای الکترونیکی را در شرکت ما بدهید.

فن آوری های COMET به شما این امکان را می دهد که به روز رسانی داده ها را در صفحه بدون دخالت کاربر سازماندهی کنید.

چت‌ها، ایمیل‌های اینترنتی و ادمین‌های چند کاربره از فهرست کاملی که در آن قابل اجرا هستند فاصله زیادی دارند.

در این سری از مقالات، نکات ظریف متعدد و راه حل های مشکلات رایج به تفصیل شرح داده شده است.

COMET چیست؟

COMET (یا "فشار سرور") روشی برای انتقال داده ها از یک سرور به یک مشتری است که توسط سرور آغاز می شود.

به عنوان مثال، شما یک فروشگاه الکترونیکی دارید و مدیر می تواند انتقال مشتری را پیگیری کند.
COMET به مدیر این امکان را می دهد که بلافاصله، آنلاین، از مشتری در مورد چیزی بپرسد، گزینه جالبی را ارائه دهد.

"Server-Initiated" به این معنی است که خود مشتری از سرور درخواست نمی کند، فقط در صفحه است.

قدیمی ترین نمونه COMET چت است. شخص فقط در صفحه است و پیام های جدیدی دریافت می کند.

COMET همچنین در پنل های مدیریت برای اطلاع رسانی به سایر بازدیدکنندگان در مورد تغییرات، برای ویرایش مشترک اسناد و غیره استفاده می شود.

روش های پیاده سازی

راه های زیادی برای پیاده سازی COMET وجود دارد. آنها ویژگی ها، مزایا و معایب مختلفی دارند.
دو کلاس اصلی وجود دارد.

طبق درخواست

مرورگر هر رویداد را در سرور با یک درخواست جداگانه دریافت می کند. در اینجا دو روش اصلی وجود دارد.

1. نظرسنجی مکرر
2. نظرسنجی طولانی

برای کاهش تعداد اتصالات و تأخیرهای ضروری، پیام‌های رویداد در بسته‌های ویژه، «داده‌گرام» بسته‌بندی می‌شوند.
به عنوان مثال، یک پیام XML ممکن است به شکل زیر باشد:

واسیا هی! در حال پردازش پردازش به پایان رسید

در اتصال بعدی، مرورگر بلافاصله کل بسته رویدادها را دریافت می کند.

مرورگر یک اتصال دائمی به سرور، به اصطلاح "کانال" را حفظ می کند و رویدادها را از طریق آن دریافت می کند.

کانال ارتباطی هر از گاهی خراب می شود:

• تا پروکسی فکر نکند که تایم اوت اتصال فرا رسیده است و آن را برای ما خراب نکند
• تا خاطره زباله های پیام های قدیمی پاک شود

علاوه بر این، برای اندازه گیری تاخیرهای شبکه و کنترل اتصال، سرور می تواند به صورت دوره ای بسته های پینگ را از طریق این کانال ارسال کند.

راه های اصلی برای حفظ یک اتصال پایدار:

1. IFrame بی نهایت
2. XMLHTTPrequest، تعاملی
3. چند قسمتی XMLHTTPRequest
4. رویداد-منبع

آنها را در مقالات دیگر این بخش خواهید یافت.

مشکلات رایج اتصال مداوم

پروتکل HTTP در اصل به گونه ای طراحی شده بود که یک درخواست یک قطعه از اطلاعات را برمی گرداند. و ما می خواهیم - بسیار، از این رو برخی از مشکلات ...

بافر پراکسی

این نادر است، اما پروکسی ممکن است مقدار مشخصی از داده را قبل از ارسال آن به مشتری بافر کند. به عنوان مثال، برای دریافت و دادن پاسخ در بلوک های 2K. در این حالت، پیام‌ها روی پراکسی باقی می‌مانند و منتظر می‌مانند تا 2K (یا هر اندازه بافری که باشد) بایت شوند و تنها پس از آن به مشتری منتقل می‌شوند.

راه حل این است که به هر پیام 2K فاصله اضافه کنید.

مشخص نیست که آیا این مشکل شما را تحت تأثیر قرار می دهد یا خیر. من امیدوارم که نه، اما در نظر گرفتن بافر پروکسی به عنوان دلیل احتمالی برای شکایت کاربران ضروری است.

نمی توان gzip کرد

IFrame که برای ارسال پیام استفاده می شود نباید با gzip/deflate فشرده شود. به عبارت دیگر، فشرده سازی باید برای پیام های URL سرویس غیرفعال شود.

فشرده سازی فعال به این معنی است که مرورگر منتظر پایان دانلود می ماند و سپس آن را از حالت فشرده خارج کرده و به کاربر نشان می دهد. در مورد ما، این کاملاً منع مصرف دارد و فشرده کردن قطعات یک صفحه (پیام) به طور جداگانه غیرممکن است.

این یک نتیجه ناگوار از ماهیت هکری iframe است. به عنوان مثال، در یک نظرسنجی طولانی، فشرده سازی عالی است، زیرا رویدادها بخشی از یک صفحه نیستند.

بافر صفحه سرور

فراموش نکنید که بافر سرور را غیرفعال کنید. در Apache/PHP - بافر خروجی را غیرفعال کنید و ob_implicit_flush را فعال کنید:

در حالی که (@ob_end_flush()) () ob_implicit_flush(1); // و البته محدودیت زمان اجرای اسکریپت را حذف کنید set_time_limit(0);

COMET: نظرسنجی مکرر در مقابل اتصال مداوم

مثل همیشه، هنگام نوشتن یک برنامه وب، سوال انتخاب معماری مطرح می شود. از یک طرف، راه حل های مربوط به اتصالات طولانی (هر چیزی به جز نظرسنجی مکرر) اطلاع رسانی سریع را ارائه می دهد. از طرفی... آیا ارتباط طولانی همیشه بهتر از نظرسنجی مکرر است؟
راه حل با اتصالات طولانی به نظر بهینه تر است، اما بسیار پیچیده تر است و دارای تعدادی ویژگی است.

1. اجرای یک اتصال طولانی، به عنوان یک قاعده، معماری را پیچیده می کند. شاید بتوانید با یک راه حل ساده تر به نتیجه برسید؟
2. تعدادی از وب سرورها برای تعداد زیادی از اتصالات طولانی مدت ضعیفی بهینه شده اند. به عنوان مثال، رشته ها یا فرآیندهایی استفاده می شوند که مقدار ثابتی از منابع را می خورند و آنها را تا پایان اتصال آزاد نمی کنند. در سطح سیستم عامل، مشکل با استفاده از kqueue (FreeBSD) یا epoll (Linux) حل می شود. سطح وب سرور، شما می توانید استفاده کنید
   1. رویداد Apache MPM برای apache 2.2 (MPM آزمایشی و محدود، دسته‌های رشته ویژه Listening و سوکت‌های Keep-Alive)
      با mod_perl/mod_php به درستی کار نمی کند
   2. سرورهای جتی (جاوا) / پیچ خورده (پایتون)، nginx و سایر سرورهای تخصصی با یک رشته/فرآیند برای بسیاری از مشتریان.

   آیا معماری سرور فعلی اتصالات طولانی را مدیریت می کند؟ پاسخ برای صدها/هزاران اتصال همزمان واضح نیست، اما فرض کنید تا 100 اتصال در هر معماری خوب است.

3. کاربران چقدر در همان صفحه می مانند؟ در طول انتقال، به احتمال زیاد اتصال باید دوباره باز شود.
4. اگر تاخیر در ارائه رویدادها قابل قبول باشد، شاید یک نظرسنجی مکرر کفایت کند؟

مدل COMET کلاسیک (مستقل از حمل و نقل).

بیایید از تعامل مشتری-سرور، بالاتر از جزئیات انتقال داده، حمل و نقل و غیره، نگاهی چشمگیر داشته باشیم. به عنوان مثال، این روشی است که در لایت استریمر تخصصی موتور فشار سرور انجام می شود.

اتصالات سرور به دو نوع تقسیم می شوند

1. اتصال کنترل - اتصالات کنترلی که از طریق آنها مشتری درخواست ها را به سرور ارسال می کند. اینها درخواست های معمولی AJAX از طریق XMLHTTPRequest هستند.
2. اتصال فشاری (کانال) - جریان رویداد، اتصالی که از طریق آن مشتری رویدادها را از سرور دریافت می کند

همه رویدادهای روی سرور دارای یک نوع هستند. یک مشتری می تواند از طریق اتصالات کنترلی مشترک شود و اشتراک رویدادهای مورد علاقه خود را لغو کند. برای راحتی، انواع توسط طرحواره ها سازماندهی می شوند. به عنوان مثال، در طرح چت، نوع پیام ممکن است باشد.

به عنوان مثال، نمودار زیر یک گردش کار معمولی را توصیف می کند:

1. کلاینت یک اتصال جریانی را به سرور باز می کند
2. مشتری در رویدادهایی از نوع Item1 در Schema1 مشترک می شود
3. سرور رویدادها را ارسال می کند
4. مشتری از طریق اتصال کنترل جدید، اشتراک رویدادها را لغو می کند
5. مشتری اتصال را می بندد

یا - در اینجا نمودار پیچیده تری وجود دارد که در آن مشتری قبلاً در انواع مختلف رویدادها مشترک شده است:

Lightstreamer از iframe به عنوان انتقال استفاده می کند. هر از گاهی باید بسته شود تا اشیاء دریافتی تمیز شوند. هنگامی که جلسه بسته می شود (هنگامی که صفحه در مرورگر به روز می شود همین اتفاق می افتد)، سرور رویدادهای جدید را تا یک بازه زمانی مشخص بافر می کند و به محض باز شدن یک جلسه Stream Connection 2 جدید از همان کاربر، آنها را ارسال می کند.

به طور کلی، بافر رویداد یک تکنیک رایج است که به شما امکان می دهد به آرامی از بسته شدن یک اتصال جان سالم به در ببرید و برای هر حمل و نقل مورد نیاز است.

در فرمت ذخیره سازی جدید، فایل لاگ می تواند صدها گیگابایت باشد. زمان نمونه برداری برای آن بسیار زیاد خواهد بود و یک مشکل پیش می آید: کار همه کاربران متوقف می شود.

علائم این مشکل عبارتند از:

دسترسی به پایگاه اطلاعات امکان پذیر نیست.

تقریباً 100٪ فعالیت روی دیسکی که log در آن قرار دارد و خواندن فعال فایل log توسط فرآیند rmngr.
این مورد را می توان با استفاده از مانیتور منبع (Task Manager - Performance - Open Resource Monitor) در برگه "Disk" بررسی کرد.
در گروه "دستگاه های حافظه" به ستون "زمان فعال (%)" توجه کنید.
در گروه "عملیات دیسک"، باید به ستون های "خواندن" و "پرونده" توجه کنید. می توان بر اساس ستون "خواندن" مرتب شد. از جمله اولین خطوط با بالاترین سرعت خواندن، فرآیند rmngr خواهد بود. در مرحله بعد، باید به نام فایل در حال خواندن نگاه کنید، این فایل مربوط به گزارش ثبت نام یک پایگاه اطلاعاتی خاص است.

در کنسول مدیریت خوشه سرور 1C: Enterprise، در لیست جلسات، تقریباً همه کاربران مقدار بزرگ و تقریباً یکسانی در ستون "DBMS captured" یا در ستون "زمان تماس (جاری)" خواهند داشت.

وقتی مشکلی پیدا شد:

به یاد داشته باشید که UID IB توسط فرآیند rmngr خوانده می شود.

اگر قبلاً شروع نشده است، مجموعه گزارش فناوری را برای رویدادهای EXCP شروع کنید.

با استفاده از کنسول مدیریت خوشه سرور 1C: Enterprise، در صورت نیاز به داده های اضافی برای تجزیه و تحلیل، همه جلسات را در سرور مشکل دار یا در IS مشکل ساز صادر کنید.

سرویس 1C: Enterprise را مجدداً راه اندازی کنید.

یک گزارش فناوری برای زمان راه اندازی مجدد سرور 1C: Enterprise جمع آوری کنید.

گزارش فناوری را تجزیه و تحلیل کنید: کلمات "Unload Log" یا "UnloadEventLog" را جستجو کنید.

مثال:

29:40.069000-0,EXCP,4,process=rphost, p:processName=ib_accounting ,t:clientID=114396,t:applicationName=1CV8C, t:ComputerName=COMP ,t:connectID=109127,SessionID=1, Usr=IvanovII ,AppID=1CV8C,ClientID=114389,Exception=NetDataExchangeException,Descr=انتقال داده به ابتکار طرف گیرنده لغو شد.,Context="Form.Call: ExternalReport.Logbook Analysis.Form.Module.BackgroundJobRun

GeneralForm.ReportForm.Form: 1242:ReportVariants.GenerateReportInBackground(Report GenerationParameters, BackgroundJob Result.ResultAddress);

GeneralModule.ReportVariants.Module: 2544: Generation = GenerateReport(Parameters, False, False);

GeneralModule.Report Options.Module: 2060: ReportObject.ComposeResult(Result.SpreadsheetDocument, Result.Decoding);

ExternalReport.Log Analysis.ObjectModule: 64:ثبت مجله آپلود(TK، انتخاب، ستون)؛"

این خط به چه کسی می گوید:ایوانوف دوم، کجا (در کدام کامپیوتر): COMP ، که در آن پایگاه اطلاعاتی: ib_accounting تجزیه و تحلیل گزارش را شروع کرد.