转--如何解决connection reset by peer(参考使用)

转--如何解决connection reset by peer(参考使用)
2010-04-28 19:33

录制c/s结构下的winsocket通信,在vuser_ini中创建连接(lrs_create_socket),在action中发送数据(send),在vuser_end中关闭连接(lrs_close_socket),但是现在的问题是在使用controller运行场景时,运行一段时间出现failed transactions,error的具体信息如下:
Action.c(18): Error : socket1 - Connection reset by peer. Error code : 10054.
查看代码发生错误的位置,发生在action中的发送数据(send)语句。
请问如何能解决这个问题,如果连接被重置(Connection reset by peer),可否自动创建新的连接,继续实现数据发送。

=========================解决方式汇总,仅供参考

经常出现的Connection reset by peer: 原因可能是多方面的,不过更常见的原因是:①:服务器的并发连接数超过了其承载量,服务器会将其中一些连接Down掉;②:客户关掉了浏览器,而服务器还在给客户端发送数据;③:浏览器端按了Stop
[10054] Connection reset by peer
Connection reset by peer is a tough one because it can be caused by so many things. In all cases, the server determines that the socket is no longer good and closes it from its side.

Read Error
Scenario: Mary couldn't make out what Joe was saying anymore, so she hung up rather than lose his messages (data). 
A read error occurs when a server cannot successfully read from a user's client. Servers gather information from the client by text, setup, and other items.When the server receives an error when reading from a client, it then disconnects the user, resulting in a read error quit message.

Write Error 
Scenario: Mary was trying to talk to Joe but didn't think she was getting through, so she hung rather than lose his messages (data). 
A write error occurs when a server cannot successfully write to a user's client. When the server receives information, it usually responds with information of its own. When the server receives an error when writing to a client, it then disconnects the user, resulting in a write error quit message similar to the read error format.

Ping Timeout Error 
Scenario: Mary, having been raised in a household with too many kids and always craving attention, keeps asking to make sure that Joe is still on the line and listening. If he doesn't reply fast enough to suit her, she hangs up. 
Servers automatically ping users at a preset time. The reason for this is to ensure the client is still connected to the server. When you see "PING? PONG!" results in your status window, it means the server has pinged your client, and it has responded back with a pong to ensure the server that you are still connected. When this does not happen and you disconnect without the server's knowledge, the server will automatically disconnect the user when it does not receive a response, resulting in a ping timeout. Ping timeouts occur to EVERYONE.

Broken pipe Error 
Scenario: Mary had picked up a sticky note with a message she needed to relay to Joe, but somehow between her hand and her mouth, the message got misplaced. Mary was trying to talk to Joe but didn't think she was getting through, so she hung up rather than lose his messages (data). 
A broken pipe error occurs when the server knows it has a message but can't seem to use its internal data link to get the data out to the socket.

Miscellaneous 
Scenario: Lots of other reasons; perhaps the operator broke in and gave Mary a message that made her doubt the validity of the call so she hung up.

方法:1、排除了程序问题

   2、排除了服务器防火墙、弑毒软件问题

   3、使用IP 欺骗无效。

Problem Description: Error: "-27780: read to host failed: [10054] Connection reset by peer"

The user gets the following error messages during replay of a Web script: 

"Error -27780: read to host <host name> failed: [10054] Connection reset by peer"
"Error -27790: Failed to read data from server <host name>" 

Diagnosis: The client sends a POST request to the server and gets a response with HTTP status 200, connection close and redirection using both JS code and meta-refresh. There is no content-length, so the client is supposed to decide when to close the connection. Internet Explorer closes the connection before sending the request to the redirection URL. But, LoadRunner does not; later the server closes the connection, and the result is the error message.



--------------------------------------------------------------------------------

Solution: Use web_set_sockets_option ("CLOSE_KEEPALIVE_CONNECTIONS", "1")

Add the following step after the POST step: 

web_set_sockets_option("CLOSE_KEEPALIVE_CONNECTIONS", "1"); 

This step closes all the open connections, and as a result, LoadRunner stops waiting for the rest of the response of the redirection.


答案其实一样,打开socket后记得关。
Connection reset by peer: socket write error错误分析及解决
2010年03月16日 星期二 下午 4:29
Connection reset by peer: socket write error错误分析:

常出现的Connection reset by peer: 原因可能是多方面的,不过更常见的原因是: 
①:服务器的并发连接数超过了其承载量,服务器会将其中一些连接Down掉; 
②:客户关掉了浏览器,而服务器还在给客户端发送数据; 
③:浏览器端按了Stop 

通常原因为:远程主机上对等方应用程序突然停止运行,或远程主机重新启动,或远程主机在远程方套接字上使用了“强制”关闭 (参见setsockopt(SO_LINGER))。另外,在一个或多个操作正在进行时,如果连接因“keep-alive”活动检测到一个失败而中 断,也可能导致此错误。此时,正在进行的操作以错误码WSAENETRESET失败返回,后续操作将失败返回错误码WSAECONNRESET。
但是如果频繁出现,就表示很 多客户端连接到Apache服务器的响应时间太长了,可能是网络的问题或者服务器性能问题。



rtsp 协议实践探究
2010-02-01 19:11
rtsp 类 http 是文本协议,但是 state-full
它需要 method 或者信令来保持 state
比如 server 端的以下信令
SETUP:
Causes the server to allocate resources for a stream and start
an RTSP session.

PLAY and RECORD:
Starts data transmission on a stream allocated via SETUP.

PAUSE:
Temporarily halts a stream without freeing server resources.

TEARDOWN:
Frees resources associated with the stream. The RTSP session
ceases to exist on the server.

对于 package 的header 的分析:
ip header中会声明:
source:202.114.99.38
destination:192.168.30.108
tcp header中会声明:
Src Port: rtsp (554), Dst Port: 14987 (14987), Seq: 3029304, Ack: 2502, 

Len: 124
RTSP Interleaved Frame, Channel: 0x00, 8016 bytes
Real-Time Transport Protocol
rtsp使用带外传输视频信息,使用 rtp 协议

以下是从官方网站中摘录的 rtsp 的一些点
A presentation or a stream is identified by a textual media
identifier, using the character set and escape conventions [H3.2] of
URLs .
一个说明或者一个流是文本描述的
URLs may refer to a stream or an aggregate of   streams, i.e., a 

presentation.
而 URL 可以指向一个流或者一群流的组合
url can refer to either presentation or an individual stream within 

presentation.
url 指向一个声明或者是一个流

以下是 协议 涉及到的3中时间表示:
SMPTE Relative Timestamps
The time code has the format   hours:minutes:seconds:frames.subframes
Normal play time (NPT) indicates the stream absolute position
relative to the beginning of the presentation.
UTC

以下是我抓包得到的信息和分析:
-------------------------------------------------------------------
Request: OPTIONS rtsp://192.168.30.107:8554 RTSP/1.0\r\n
CSeq: 1\r\n
User-Agent: RealMedia Player (HelixDNAClient)/10.0.0.0 (win32)\r\n
ClientChallenge: a58f5ddf324d4a1ab6f864f6d3ff3fda\r\n
ClientID: WinNT_5.1_10.0.0.0_play32_RN01_EN_686\r\n
PlayerStarttime: [01/02/2010:16:36:34 -08:00]\r\n
Pragma: initiate-session\r\n
RegionData: 0\r\n
\r\n

Response: RTSP/1.0 200 OK\r\n
CSeq: 1\r\n
Date: Mon, Feb 01 2010 08:36:39 GMT\r\n
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, 

SET_PARAMETER\r\n
\r\n
------------------------------------------------------------------
//retrive description from the server and use accept to ask for 

understand
Request: DESCRIBE rtsp://192.168.30.107:8554/mp3AudioTest RTSP/1.0\r\n
CSeq: 2\r\n
User-Agent: RealMedia Player (HelixDNAClient)/10.0.0.0 (win32)\r\n
Accept: application/sdp\r\n
Bandwidth: 10485800\r\n
ClientID: WinNT_5.1_10.0.0.0_play32_RN01_EN_686\r\n
Language: zh-CN\r\n
RegionData: 0\r\n
Require: com.real.retain-entity-for-setup\r\n
SupportsMaximumASMBandwidth: 1\r\n

Response: RTSP/1.0 200 OK\r\n
Content-Base: rtsp://192.168.30.107:8554/mp3AudioTest/\r\n
Content-type: application/sdp
Content-length: 380
\r\n
Owner/Creator, Session Id (o): - 1265003496893394 1 IN IP4 

192.168.30.107
Session Name (s): Session streamed by "testOnDemandRTSPServer"
Session Information (i): mp3AudioTest
Time Description, active time (t): 0 0
Session Attribute (a): tool:LIVE555 Streaming Media v2010.01.22
Session Attribute (a): type:broadcast
Session Attribute (a): control:*
Session Attribute (a): range:npt=0-269.187(normal play time)
Session Attribute (a): x-qt-text-nam:Session streamed by 

"testOnDemandRTSPServer"
Session Attribute (a): x-qt-text-inf:mp3AudioTest
Media Description, name and address (m): audio 0 RTP/AVP 14
Connection Information (c): IN IP4 0.0.0.0
Bandwidth Information (b): AS:128
Media Attribute (a): control:track1
--------------------------------------------------------------------
Request: SETUP rtsp://192.168.30.107:8554/mp3AudioTest/track1 RTSP/1.0

\r\n
CSeq: 3\r\n
Transport: RTP/AVP;unicast;client_port=6970-

6971;mode=play,RTP/AVP/TCP;unicast;mode=play
User-Agent: RealMedia Player (HelixDNAClient)/10.0.0.0 (win32)\r\n
\r\n

Response: RTSP/1.0 200 OK\r\n
CSeq: 3\r\n
Date: Mon, Feb 01 2010 08:36:40 GMT\r\n
Transport: 

RTP/AVP;unicast;destination=192.168.30.108;source=192.168.30.107;client

_port=6970-6971;server_port=6970-6971
Session: 655A964F
\r\n

//setup 信令可能引起 455 Method Not Valid In This State
-------------------------------------------------------------------
//The PLAY method tells the server to start sending data via the
mechanism specified in SETUP ,在 describe 得到视频文件信息后,用

setup 相当于协商,协商后 play
在 PLAY 中会声明 range ,如不声明,则是从 begining
-------------------------------------------------------------------
//GET_PARAMETER with no
entity body may be used to test client or server liveness
-------------------------------------------------------------------
//SET_PARAMETER
1、一次只能设置一个 param
2、server 可以 disallow 设置某变量
Request: SET_PARAMETER rtsp://192.168.30.107:8554/mp3AudioTest 

RTSP/1.0\r\n
CSeq: 4\r\n
frame[127:44] == 

53:75:62:73:63:72:69:62:65:3a:20:73:74:72:65:61:6d:3d:30:3b:72:75:6c:65

:3d:30:2c:73:74:72:65:61:6d:3d:30:3b:72:75:6c:65:3d:31:0d:0a
Session: 655A964F
\r\n

Request: PLAY rtsp://192.168.30.107:8554/mp3AudioTest RTSP/1.0\r\n
CSeq: 5\r\n
User-Agent: RealMedia Player (HelixDNAClient)/10.0.0.0 (win32)\r\n
Session: 655A964F
Range: npt=0-269.187000
\r\n
-------------------------------------------------------------------
//REDIRECT
S->C
-------------------------------------------------------------------
//RECORD
用 UTC 表明 start end

备注:
如果要探究 标准的 rtsp 
最好使用 vlc player
其它如暴风处理 rtsp 的方式有问题,如 mediaPlayer 它支持的不是标准的 

rtsp(处理 rtsp 的方式是微软的一套).


关于RTSP的理解和例子说明
2008-11-23 21:58

rtsp是real time streaming protocol,按照我的理解为流媒体控制协议,协议双方的的编码类型和地址,以及对stream media的控制(play,pause,record).注意这里不要与RTCP协议搞混,rtcp是用来控制rtp的.

下面通过介绍RTSP的几种方法来说明协议
1:options 
这个通常由client发送server,询问服务器所支持的方法种类,当然在应用中也可以用来作为心跳,因为它是状态无关的.例如:
C->S:       OPTIONS * RTSP/1.0
            CSeq: 1
            Require: implicit-play
            Proxy-Require: gzipped-messages

S->C:       RTSP/1.0 200 OK
            CSeq: 1
            Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
服务端发送的200ok里表明服务端支持describe,setup,teardown,play,pause.
在这里可以看到请求和响应的cseq相同,对应后面所有的消息,请求和响应的cseq都是相同的.

2:describe
按照字面意思,就是描述,描述什么呢?当然是流媒体的信息呢,在返回的应答中包含SDP.举个例子
DESCRIBE rtsp://server.address:port/object.sdp RTSP/1.0\r\n
CSeq: 1\r\n
\r\n

-----------------------------------------------------------------------
RTSP/1.0 200 OK\n
Server: QTSS(IFI)/v88\n
Cseq: 1\n
Content-Type: application/sdp\n
Content-Base: rtsp://bildeus.ifi.uio.no:8000/12.sdp/\n
Content-length: 785\n
\n
n=2236805513 2236805513 932036356 224.2.127.254 9875 127 trusted\n
v=0\n
o=yozo 3138827440 3138828177 IN IP4 aohakobe.ipc.chiba-u.ac.jp\n
s=Places all over the world\n
i=Low bandwidth video (10kb/s) with views from all over the world. Audio is primarily for feedback for the senders of video. (looks like there's some problem for the session announcement from sweden distributes to the whole MBone, I'm repeating the announcement from japan. -- yozo.)\n
e=Yozo TODA at IPC, Chiba University, JAPAN <yozo@ipc.chiba-u.ac.jp.>\n
p=+81-43-290-3539\n
c=IN IP4 224.2.213.113/127\n
t=3138827400 3141246600\n
a=tool:sdr v2.6.1\n
a=type:test\n
m=audio 20154 RTP/AVP 0\n
c=IN IP4 224.2.213.113/127\n
a=ptime:40\n
a=control:trackID=1\n
m=video 51482 RTP/AVP 31\n
c=IN IP4 224.2.172.238/127\n
a=control:trackID=2\n

在应答中, 我们重点关注SDP字段.在SDP中,我们看到了流媒体包含了2个资源(m行):audio和video,其中a行是m(media)的属性描述.在m行中,中间的数字为服务端推荐客户端接收的端口,如果服务端不想这样做,可以将port置为0.在sdp中,还有a=control字段,在rfc2326中,对其的解释如下:

   The "a=control:" attribute is used to convey the control URL. This
   attribute is used both for the session and media descriptions. If
   used for individual media, it indicates the URL to be used for
   controlling that particular media stream. If found at the session
   level, the attribute indicates the URL for aggregate control.

   Example:
     a=control:rtsp://example.com/foo

   This attribute may contain either relative and absolute URLs,
   following the rules and conventions set out in RFC 1808 [25].
   Implementations should look for a base URL in the following order:

   1.     The RTSP Content-Base field
   2.     The RTSP Content-Location field
   3.     The RTSP request URL

   If this attribute contains only an asterisk (*), then the URL is
   treated as if it were an empty embedded URL, and thus inherits the
   entire base URL.

   
这里我们对集合控制(aggregate control)进行说明.当服务端支持集合控制,比如对一个音频视频流,它就不需要建立2个session,集合成一个session就ok,如果不支持就得分别建立2个session.我的理解a=control即是对媒体的标识:比如track1表示视频,track2表示音频.在后续的setup中可以看到这点.
通过SDP这些参数我们就可以知道流媒体的编码格式.

3:setup
建立会话,如果支持集合控制,在setup中会包含session字段.下面的消息是支持集合操作的例子.

SETUP rtsp://server.address:port/object.sdp/trackID=1 RTSP/1.0\r\n
CSeq: 2\r\n
Transport: RTP/AVP;unicast;client_port=9000-9001\r\n
\r\n
-------------------------------------------------------------------------

RTSP/1.0 200 OK\n
Server: QTSS(IFI)/v88\n
Cseq: 2\n
Session: 1234567890;timeout=60
Transport: rtp/avp;source=129.240.65.208;server_port=9000-9001;client_port=9000-9001\n
\n
--------------------------------------------------------------------------
SETUP rtsp://server.address:port/object.sdp/trackID=2 RTSP/1.0\r\n
CSeq: 3\r\n
Session: 1234567890\r\n
Transport: RTP/AVP;unicast;client_port=9000-9001\r\n
\r\n

在例子中我们看到,通过setup的响应,即建立了流媒体的会话.后续的setup必须带上session字段,通过上面的消息我们看到客户端发送了2次setup,分别是代表video的track1和audio的track2.如果服务端不支持集合操作,那么setup里带上session字段则是非法的.在消息中,我们看到了transport字段,在这里表明了客户端接收流媒体的端口,以及编码格式.在本例中采用的是udp方式传送RTP,如果采用TCP的方式传送RTP,则可能transport 字段为:Transport: RTP/AVP/TCP;unicast;interleaved=0-1 ,这里解释下interleaved,因为采用TCP方式传送,所以传送的RTP,RTCP包都在同一个链路上,需要区分,所以有了interleaved,0表示是RTP的通道,1表示是RTCP的通道.体现在包上面就是在RTP,RTCP包上封装了一层interleaved frame,格式如下:
Magic:0x24
Channel:0x01(表示RTCP)
Length:84


4:play
play 即对流媒体的播放指令:
PLAY rtsp://server.address:port/object.sdp RTSP/1.0\r\n
CSeq: 4\r\n
Session: 1234567890\r\n
\r\n
通常在play中有range字段,但不是必需的.这个字段表示播放的流媒体的范围.

5:teardown
teardown指令即对流媒体的结束
在teardown中是否必须带有session,我们曾经进行过讨论.如果一个session对应一个链路,则可以不需要对应session,但是在我们遇到的应用中,teardown基本都是携带了teardown.谈到这里,我们说下RTSP的几种连接类型:
* persistent transport connections used for several request-response transactions
* one connection per request/response transaction;
* connectionless mode.

对几种基本的消息的介绍就到这里了,我们现在来谈谈RTSP的状态机.其实RTSP的状态机很简单,不像sip协议那么复杂.对应很多消息,是状态无关的.现在这里只介绍与服务器相关的状态机:
     state           message received     next state
     Init             SETUP                    Ready
                         TEARDOWN          Init
     Ready           PLAY              Playing
                     SETUP             Ready
                     TEARDOWN          Init
                     RECORD            Recording
     Playing         PLAY              Playing
                     PAUSE             Ready
                     TEARDOWN          Init
                     SETUP             Playing
     Recording       RECORD            Recording
                     PAUSE             Ready
                     TEARDOWN          Init
                     SETUP             Recording
通过上面的表,我们就可以知道消息的发送必须是有序的,比如还没有发送setup,就不能发送play.还有连续2次的pause肯定是错误的.在这个状态机中,是没有结束的,我们通常teardown后一个会话就会结束,甚至会关闭链路.但是在上图中又回到了init状态,我对此有些迷惑,这里又要提到了上面我们讨论的话题:teardown是否该带session,在这个状态机中,在任何阶段都可以接收teardown,比如init阶段,这个阶段是没有session的.

PS:这篇是在DR的最后一个项目(全球眼)结束后写的一篇总结。如今看来,却有部分连自己都不懂了。




展开阅读全文

没有更多推荐了,返回首页