検索

ダイジェスト
· 2025年11月17日

Publications des développeurs d'InterSystems, semaine Novembre 10 - 16, 2025, Résumé

ダイジェスト
· 2025年11月17日

Join the InterSystems “Bringing Ideas to Reality” Contest

Dear Community member,

The next big InterSystems programming contest is here:

💡 InterSystems "Bringing Ideas to Reality" Contest 🏆

Turn an idea from the InterSystems Ideas Portal that has status Community Opportunity or Future Consideration and show the world what you can build.

🏆 Prize Pool: $12,000
💰 Up to $5,000 from our experts
🌟 Community prizes up to $1,000

Key Dates:

  • Contest runs: November 17 – December 7, 2025
  • Submit your app by November 30, 2025
  • Voting: December 1–7, 2025

Don’t miss your chance to turn an idea into reality and win big!

Read the rules here.

ダイジェスト
· 2025年11月17日

【週間ダイジェスト】 11/10 ~ 11/16 の開発者コミュニティへの投稿

記事
#InterSystems IRIS
PEP 8入門
Toshihiko Minamoto順
#InterSystems IRIS for Health
お知らせ
11/10 ~ 11/16Week at a GlanceInterSystems Developer Community
ダイジェスト
· 2025年11月16日

InterSystems 开发者社区中文版:每周摘要(2025年11月10日-16日)

十一月 10 - 16, 2025Week at a GlanceInterSystems Developer Community
記事
· 2025年11月16日 2m read

Network Debugging for Beginners - 2

In my previous article, I structured network communications
in these 3 possible layers, and covered the last

  • Client <---> Transport
  • Server <---> Transport
  • Client <---> Server

In fact, you have the most control over the last one.
The IRIS side as a server is yours and under your full control. 
Up to now, the Transport layer was assumed to be as passive as a bare wire.

This assumption should be verified. I once met a Windows environment with
a quite surprising setup where a Firewall-like filter was isolating internal
processes and causing a lot of trouble.

? What can you do about the  Transport section ?

In a typical setup, firewalls filter and/or block selected connections by Web Address
or by type of protocol.  WebSockets seems to be one of their preferred targets.  
And even Microsoft's IIS requires special settings to pass along the WebSocket protocol.

Now we have reached the wire. If there is no direct connection as in a LAN,
every router you have to pass is expected to just forward messages.
Though they might also be a show stopper, acting like a firewall.

It's eventually a rare case, but it could never be excluded.
And there is still another dimension related to the Transport.
Earlier we have seen what we think to receive and what we expect to send.

? Is this the reality out on the wires ?

I know of 2 tools I have used that helped me along often.
Both act by the same principle as a tunnel and mimic client and server.
Receive messages, log them with timestamps, and forward them to the other end.

The ultimate tool is Wireshark. I guess no bit on the wire can escape from it.
Though it is easy to start, the correct interpretation is a science that requires
related experience and deep digging into details.
Being in networks for almost 60 years, it was the best tool in that area I have ever met.
It is to me what Mona Lisa might be for painters or Mount Everest for climbers.

But in most average troubleshooting exercises it's an overkill.
TCPtrace creates a tunnel and keeps track of what is going forward and back.
For some time, it is also able to handle UDP protocol too.
And it is really easy to handle and to consume! 

As you have seen in the simple example with  our management portal:

  • What you see in IRIS in the CSP page is HTML and JavaScript
  • What you see in the browser is also just HTML and JavaScript
  • But invisible and under cover, headers and cookies are traveling along

You may face situations where your problem is exactly hidden there.
The experiment with manually composed HTML showed it.

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください