|
|
|||||||
| 論壇說明 |
|
歡迎您來到『史萊姆論壇』 ^___^ 您目前正以訪客的身份瀏覽本論壇，訪客所擁有的權限將受到限制，您可以瀏覽本論壇大部份的版區與文章，但您將無法參與任何討論或是使用私人訊息與其他會員交流。若您希望擁有完整的使用權限，請註冊成為我們的一份子，註冊的程序十分簡單、快速，而且最重要的是－－註冊是完全免費的！ 請點擊這裡：『註冊成為我們的一份子！』 |
 |
|
|
主題工具 | 顯示模式 |
2003-05-12, 12:50 AM
|
#1 |
|
|
請問MSN調教高手...
我的網路是在人家的防火牆下....
要傳資料都沒辦法傳.... 請問有沒有人知道.... msn傳資料的port怎麼改啊... 若能把他改成ftp的port21 不知道能否傳.... 請問高手....謝謝囉 |
|
送花文章: 0,
|
|
2003-05-12, 04:32 AM
|
#6 (permalink) |
|
|
1.open port 1863
open port 6981 - 6900 2.在 Messenger 主視窗上，按一下 [工具] 功能表，按一下 [選項]，再按 [連線] 索引標籤。 請注意在此索引標籤中所需要的資訊。 請提供所有網路使用者在其 MSN Messenger 程式中正確設定 [連線] 索引標籤所需的資訊和指示。 請確認內部的區域網路可以存取「網域名稱系統」(DNS) 伺服器，來解決如「messenger.msn.com.tw」等外部主機的名稱問題 3.i use http proxy in 索引標籤(Messenger 主視窗上，按一下 [工具] 功能表，按一下 [選項]，再按 [連線] 索引標籤。 ) isp is ethome(東森寬帶),no dmz router,二台電腦沒有使用真實ip,一台有真實ip,no problem can work,if you have any question you can go http://redhat.ecenter.idv.tw/ 高手比較多（台灣有些高手真不簡單),或得不到滿意的答案,可問a471 or 不飛 http://www.microsoft.com/windowsxp/p...atfw/natfw.doc The following Windows Messenger features affected by NAT and firewall issues are: Instant Messaging and Presence In general, there are no issues with IM and presence affecting communication through a firewall or NAT device. If the Windows XP client can create and maintain a connection to the server, other IM and presence communication can follow this same path. For example, Microsoft Exchange IM transports its Presence and IM messages using hypertext transfer protocol (HTTP) and has mechanisms to insure that these messages can traverse firewall and NAT devices. These mechanisms include polling to maintain a TCP connection to the server for two-way communication and setting aside a fixed port for callback delivery. When a session initiation protocol (SIP) solution is used, the data may be sent using TCP, UDP or secure sockets layer (SSL). SIP signaling may also use dynamic ports, which may require opening the entire range of ports on a firewall. If a NAT device is placed between SIP clients and their servers, differences may exist between the ports and addresses reflected in the SIP messages and the actual ports and addresses. Windows Messenger has mechanisms to overcome these issues and are discussed later in this article. Audio and Video When negotiating an audio-video session, dynamic ports were chosen for the audio-video (AV) stream. Dynamic ports are used to enable the application to work regardless of what other applications are running on the system and using port resources. In the .NET Messenger case the session invitation was sent by station B to the address it received for station A. The following issues might arise if a firewall or NAT were present in these scenarios: • The address provided by A in either the session invite for session signaling, or in the session acceptance for the UDP streams, might be an internal address that is translated by a NAT device—an invalid (or fake) address for B to use to contact A. In other scenarios with the 4.5 client, A might initiate the session, but the same or similar addressing issues will exist. • When B sends the session invitation to A, this invitation is sent using the IP address and port passed from A to B. For this to work, this port must be enabled to pass through any firewall between A and B. • The actual Real-time Transport Protocol (RTP) streams are sent using dynamically allocated UDP ports in the range of 5004 – 65535. Without a way to open these UDP ports on any firewall in the path dynamically, the streams will fail to reach their destination. Non-UPnP NAT Devices Windows Messenger peers, separated by a NAT device that cannot be detected, should be able to use IM and Presence. This is true whether the network service being used is .NET Messenger, Exchange IM, or a SIP solution. Clients using SIP servers also work because logic has been added to the client to ensure communication when the server is opened. Issues arise, as described earlier in this article, with the other features of Windows Messenger. The following points relate to those issues: • IM and Presence are implemented through a mediating server with a direct TCP connection initiated by the client when using .NET Messenger or Exchange IM. This should not present any NAT or firewall issues. Sessions or connections initiated by clients external to the NAT device will not succeed because the internal client cannot provide the NAT-translated address to the peer. In the case of AV this applies to calls made by the internal client to the external client, because the external client is the one initiating the SIP session. If the external client calls the internal client, the failure occurs later in the process. The internal client can send the SIP invite to the external client, but the address passed in this invite is incorrect. • Calls made between peers on the same side of the NAT device should work. • An application layer gateway (ALG) for SIP may alleviate some of these problems. ALGs can be used as an application level filter for specific applications and protocols. Administrator/User Action Required To enable voice and video communications with Windows Messenger through a non-UPnP firewall, configure the firewall to allow incoming traffic on UDP ports 5004 – 65535. For other purposes, enable the following ports: • File Transfer: 6891 (to allow 10 simultaneous file transfers open ports 6891 through 6900) • Application and Whiteboard Sharing: 1503 • Remote Assistance: 3389 |
|
送花文章: 0,
|
平板模式
