A connection abort was caused internal to your host machine. The software caused a connection abort because there is no space on the socket's queue and the socket cannot receive further connections.
WinSock description: The error can occur when the local network system aborts a connection. This would occur if WinSock aborts an established connection after data retransmission fails (receiver never acknowledges data sent on a datastream socket).
TCP/IP scenario: A connection will timeout if the local system doesn't receive an (ACK)nowledgement for data sent. It would also timeout if a (FIN)ish TCP packet is not ACK'd (and even if the FIN is ACK'd, it will eventually timeout if a FIN is not returned).
It seems to happen more with WindowsXP and it seems also to be possibly related to Windows firewall settings. In any case the salient point is that the abort has originated inside the local machine.
It's a stupidly worded message.
Error Message: Software caused connection abort.
Explanation:
This error can occur when the local network system aborts a connection, such as when Winsock closes an established connection after data retransmission fails (receiver never acknowledges data sent on a datastream socket).
User Action:
Check the following:
1. Ping the remote host you were connected to. If it doesn't respond, it might be offline or there might be a network problem along the way. If it does respond, this problem might have been a transient one (so you can reconnect now), or the server application you were connected to might have terminated (so you might not be able to connect again).
2. Ping a local host to verify that your local network is still functioning (if on a serial connection, see next step).
3. Ping your local router address. If you are on a serial connection, your local router is the IP address of the host you initially logged on to using SLIP or PPP. 4. Ping a host on the same subnet as the host you were connected to (if you know of one). This will verify that the destination network is functioning.
5. Type tracert at the command prompt to determine the path to the host you were connected to. This won't reveal too much unless you know the router addresses at the remote end, but it might help to identify if the problem is somewhere along the way.
어떤 사람들은 socket timeout시간을 늘렸더니 해결되었다는 사람들도 있습니다.
흠 저도 늘려서 해봤는데 이 문제는 아닌거 같더군요.
Software caused connection abort Error: An established connection was aborted by the software in your host machine. Software caused connection abort.
This error can occur when the local network system aborts a connection, such as when WinSock closes an established connection after data retransmission fails (receiver never acknowledges data sent on a data stream socket), possibly due to a data transmission timeout or protocol error.
You may try to set the Connection Timeout higher (Default: 60s). If the problem persists change the Data Connection Mode from "Port Mode (PORT)" to "Passive Mode (PASV)" or vice versa. For further information on how to switch between Active and Passive mode please see the following Knowledge
In modern versions of PuTTY, you should not see this error.
Windows's documentation about this error condition is not very good, but as far as we can tell, this error occurs when PuTTY is listening on a port, another program makes a connection to that port, but closes the connection so fast that PuTTY has no time to answer it.
If you are getting the error in the middle of session, it means that Windows network code killed an established connection for some reason. For example, it might happen if you pull the network cable out of the back of an Ethernet-connected computer, a DHCP IP address renewal fails or changes the computer’s IP address, or if Windows has any other similar reason to believe the entire network has become unreachable.
Windows also generates this error if it has given up on the machine at the other end of the connection ever responding to it. If the network between your client and server goes down and your client then tries to send some data, Windows will make several attempts to send the data and will then give up and kill the connection. In particular, this can occur even if you didn’t do anything, if you are using SSH-2 and WinSCP attempts a key re-exchange.
The problem can be caused also by the firewall. Try to disable it temporarily to see if the problem persists. Refer to FAQ. It can also occur if you are using keepalives in your connection. Other people have reported that keepalives fix this error for them.1) If you find DHCPNACK errors in the Event Viewer, your DHCP server may be briefly denying your IP address, causing your existing connections to fail. Where possible, this can be addressed by reserving a specific IP address on the DHCP server (e.g. cable modem/router), setting that as the static IP address, and disabling the DHCP client service.
아래 사람도 저랑 비슷한 경우인거 같습니다.
저도 첫번째 시도시는 잘 되는데... 두번째 시도할 때는 exception이 발생하더군요...
그리고 천천히 write를 하는게 아니라 좀 빨리 write를 하면은 정상적으로 동작합니다.
서버쪽에서 소켓을 닫아 버리는데, data를 받고서 어느 정도 기다렸다가 닫아버리는지 연속적으로 빠르게 data를 보내면 제대로 동작하더라고요. 결국에는 서버쪽에서 소켓을 닫아 버렸다고 생각할 수도 있는데 흠흠.. 아직 정확하지 않기 때문에 확인해보고 이야기 드리겠습니다.
Ladies, I also keep getting the same error message
but it's always after my 2nd attempt to communicate through the socket. The first attempt is fine.
Since I wrote the program for the server, I don't understand how it can be closing the connection to my client program (which I also wrote). I am not closing anything except data ports after data is transferred.
이런... 공부할게 넘쳐 나는구나.... 너무 행복하다... ㅠ_- 너무 행복해서.... 욕도 나온다.... ㅠ_-
이번에는 Keep Alive message에 대해서 알아봅시다. 근데 이것도 만만치 않게 자료가 없다.. 아흑 ㅠ_- 먼저 이번 포스트에서 다룰 내용은 HTTP Keep Alive가 아니라, TCP Keep Alive입니다.
TCP Keep Alive에 대해서 공부하기 전에 HTTP Keep Alive에 대해서 간단히 공부하는 것도, 괜찮을 것 같아서 간단히 정리해봅니다.
HTTP는 connection less방식이라 매번 socket(port)를 열어야 하고 이는 비용적인 측면에서 비효율적인 구조입니다. 해서 keep Alive time out내에 client에서 request를 재 요청하면 socket(port)를 새로 여는 것이 아니라 이미 열려 있는 socket(port)에 전송하는 구조가 됩니다.
킵얼라이브 메시지란, 한 네트웍이 다른 네트웍 장치에게 둘 사이의 가상회선이 아직 활성 상태임을 알려주기 위해 보내는 메시지를 말한다. BGP는 동료들이 도달가능한지를 확인하기 위해, 충분히 자주 킵얼라이브 메시지를 서로 교환하여 대기시간이 종료되지 않도록 한다. 킵얼라이브 메시지를 주고받는데 적당한, 최대 시간 주기는 대기시간 간격의 약 1/3 정도이다. 킵얼라이브 메시지는 메시지 헤더로만 구성되어 있고, 19 옥텟의 길이를 가지고 있다.
A keepalive signal is often sent at predefined intervals, and plays an important role on the Internet. After a signal is sent, if no reply is received the link is assumed to be down and future data will be routed via another path until the link is up again.
Since the only purpose is to find links that don't work, keepalive messages tend to be short and not take much bandwidth. However, their precise format and usage terms depend on the communication protocol.
미리 정해진 interval마다 keepalive메세지를 보내서 no reply시에 link가 다운되었다고 판단하고 다른 path로 data를 전송한다. 뭐 이런 이야기 인데...
keepalive signal에 대해서 no reply가 단 한번이라도 발생되면은.. 바로 down되었다고 판단하는건가??? 흠..
TCP Keep Alive
According to RFC 1122, TCP Keep-alives is an optional feature of the protocol, and if included must default to off.
There are three parameters related to keepalive, viz. Time, interval and retry.
- Keepalive time is the duration between two keepalive transmission in idle condition. TCP keepalive period is required to be configurable and by default is set to no less than 2 hours.
- Keepalive Interval is the duration between two successive keepalive retransmissions, if acknowledgement to the previous keepalive transmission is not received.
- Keepalive Retry is the number of retransmissions to be carried out before declaring that remote end is not available.
Keepalive packet contains null data. In a TCP/IP over ethernet network, a keepalive frame is of 60 bytes, while acknowledge to this also null data frame and is of 54 bytes.
TCP Keep-alives는 옵션이군요. Keep alive의 parameters를 설명하고 있는데... 저는 너무 깊이 들어가지 않아도 되는지라... ㅎㅎ
서버와 클라이언트간에 TCP 연결이 이루어지면, 클라이언트측에서 접속을 끝내는 FIN 신호를 보낼 때에만 접속이 해제된다. 만약에 intermediate router가 crash 혹은 reboot되거나 선로가 down 되어도, 서버는 reboot하지 않는 이상 이러한 상황을 알아낼 방법이 없으므로 connection은 유지된다. 이와 같은 상태를 Half open connection이라고 한다. Keepalive timer는 서로 연결된 호스트간의 connection이 여전히 유효한지, 즉 half open connection 상태가 아닌지 점검하기 위하여 사용되는 타이머이다. Keepalive option은 주로 server쪽에 설정되며 주기는 서버에서 정하기 나름이다. 만일 주어진 timer동안 activity가 없으면 client로 probe를 보낸 후 response를 받지 못하면 connection을 종료한다.
자료를 검색하다 보면은 Keepalive에 대한 설명은 많은데... 어떻게 동작하고 패킷 분석이나 이런건 찾기가 힘드네요 ㅠ_-
오~ 괜찮은 자료가 있습니다.
GNU Gatekeeper라는 사이트인데요. TCP keepalive를 이용해서 Network Error를 감지하는 방법에 대해서 설명하고 있는것 같습니다. 제가 지금 테스트 해볼 상황은 아니라서 테스트는 하지 않았지만.... 나중에 테스트 해보고 추가 포스팅하겠습니다.
To detect network errors and signaling connection problems, you can enable tcp keep alive feature. It will increase signaling bandwidth used, but as bandwidth utilized by signaling channels is low from its nature, the increase should not be significant. Moreover, you can control it using keep alive timeout.
The problem is that most system use keep alive timeout of 7200 seconds, which means the system is notified about a dead connection after 2 hours. You probably want this time to be shorter, like one minute or so. On each operating system, the adjustment is done in a different way.
After settings all parameters, it's recommened to check whether the feature works correctly - just make a test call and unplug a network cable at either side of the call. Then see if the call terminates after the configured timeout.
일단 현재 문제가 되고 있는 시스템의 OS가 Linux이므로 Linux관련된 내용만 다루겠습니다. 다른 OS들은 해당 링크를 통해서 학습하시길 바랍니다.
Use sysctl -A to get a list of available kernel variables and grep this list for net.ipv4 settings (sysctl -A | grep net.ipv4).
There should exist the following variables: - net.ipv4.tcp_keepalive_time - time of connection inactivity after which the first keep alive request is sent - net.ipv4.tcp_keepalive_probes - number of keep alive requests retransmitted before the connection is considered broken - net.ipv4.tcp_keepalive_intvl - time interval between keep alive probes
You can manipulate with these settings using the following command:
This sample command changes tcp keepalive timeout to 60 seconds with 3 probes, 10 seconds gap between each. With this, your application will detect dead tcp connections after 90 seconds (60 + 10 + 10 + 10).
sysctl은 Redhat 6.2부터 포함된 Kernel parameter 값들을 조절하기 위한 UTIL이랍니다.
기술 세미나 주제는 "DTMF on VoIP"( 세미나 주제 제목이 그럴싸함 으흐흐 ^_________^)
팀내 기술 세미나라서 많은 인원이 참석하지는 못했지만.. 그래도 프로젝트 뛰면서 틈틈히 한달 정도 공부하면서 준비했던거라서 시간이 부족하지는 않았습니다.
물론 세미나가 끝나고 QnA 시간에 H.323관련 질문을 하셔서 답변은 못해드렸지만...
아는 만큼 나름 답변을 ^__________________^
아래와 같은 질문을 받았는데.. 예상치도 못한 질문이라 답변을 못드렸습니다.
VoIP에서 DTMF tone 전송 방식에 대하여 준비하였는데... ㅎㄷㄷ;;
암튼... 일단 세미나가 끝난 후에 따로 테스트를 하였습니다....
*혹시 아래 내용중에 틀린 내용이 있으면 꼭 댓글 부탁드립니다. 제가 이것 저것 검색하면서 공부한 것이라 부족하고 틀린 내용이 있을 수 있습니다. 비밀글 아니어도 상관이 없습니다. 정확한 정보 전달을 목적으로 하기 때문에, 전혀 민망해 하지 않습니다. 고수님들의 지식을 꼭 전수해주시기 바랍니다.
질문 내용은
RFC2833방식에서 digit버튼을 누르고 있는 동안에 call을 종료할 때에 어떻게 동작하는지에
대하여 테스트를 해보았습니다.
1. digit을 누르고 있는 동안에 랜선을 뽑았을 때
2. digit을 누르고 있는 동안에 Call 종료 버튼을 눌렀을 때
테스트 장비는 삼성 VoIP전화기(이거 테스트 다 거치고 출시한 제품인데 버그가 좀 있음)와 EyeBeam 소프트폰입니다.
그런데 문제는 삼성 VoIP전화기에서는 DTMF duration이 안됩니다.
버튼을 길게 누를 수 없게
되어 있습니다. DTMF는 정확하게 전송이 되나 버튼을 길게 누르고 있으면 "띠~~~~~~~"소리가 계속 나는게 아니라.
"띠~익"하고 바로 end message(Inband방식에도 불구하고)를 전송하더라고요. 이것은 제조사마다 DTMF tone 생성 방식이 틀릴 수 있다고 합니다.
DTMF duration이 제대로 작동하지 않으므로, 삼성폰->eyebeam의 경우를 테스트를
할 수 없어서 eyebeam->삼성폰 으로 테스트를 했습니다.
- 버튼을 누르고 있는 동안에 LAN선을 뽑았을 때,
당연히 END message가 전송이 안됩니다. END message는 버튼에서 손을 뗄때 전화기에서 만들어서 보내지는데, 아직
손을 떼지 않았기 때문입니다. 뭐 이것은 테스트 안해도 아시겠지만.. 정확한 것이 좋기 때문에 테스트를 해봤습니다.
- 버튼을 누르고 있는 동안에 Call End 버튼을 눌렀을 때,
버튼을 누르고 있는 동안에 DTMF tone은 계속적으로 전송이되며, call
end버튼을 누를 때 마다 end메시지는 전송이 됩니다만, 호는 계속적으로 established되어 있습니다.
이게 아마 소프트적으로 "2"번 버튼을 누르고 있다가 다른 버튼을 누르게 되면은
순간 "2"버튼에서 손을 떼었다고 생각하여 end message를 보내는 것 같습니다.
아래는 테스트하면서 알게 된 점입니다.
DTMF를 생성하는
방식은 제조사 마다 틀린 것 같습니다. (DTMF 생성 방식과 전송 방식
구분)
아래 표는 삼성폰 -> 소프트폰, 소프트폰 -> 삼성폰 으로 테스트를 한 결과
입니다.
삼성 VoIP폰 -> 소프트 폰
소프트 폰 -> 삼성
VoIP폰
Bypass
버튼을 계속 누르고 있을 수 없음.
버튼을 누르고 있어도 Local DTMF tone이 짧게 생성. 수신측에서도 짧은 DTMF
tone을 들을 수 있음.
버튼을 누르고 있는 만큼 Local DTMF tone발생. 수신측에서도 동일한 duration만큼
DTMF tone을 들을 수 있음.
RFC2833
버튼을 계속 누르고 있을 수 없음.
버튼을 누르고 있어도 end message를 바로 전송해버림. Local DTMF tone도 짧게 생성됨.
버튼을 누르고 있는 동안 DTMF tone발생, end message는 손을 뗄때
전송.
SIP INFO
버튼을 한번 누르고 나서 짧은 시간 후 DTMF tone발생(발신자와 수신자간에 DTMF tone
시간 차이가 있음)
버튼을 누르고 짧은 시간 후에 DTMF tone 발생(발신자와 수신자간에 DTMF tone
시간 차이가 있음)
결론적으로, VoIP폰이든 소프트폰이든 DTMF 전송 방식은 동일합니다.
(bypass의 경우 음성코덱으로 압축(payload type 0), RFC2833의 경우
rtpevent(payload type 101), SIP INFO의 경우 SIP INFO method이용)
하지만 DTMF 생성 방식은 제조사마다 다르게 동작하는 것 같습니다.
RFC2833의 방식은 Inband방식이기 때문에 버튼을 누르고 있는 동안 계속적으로 DTMF
tone을 수신자측에 보내주어야 하지만, 삼성 폰에서는 버튼을 누르고 있어도 바로 end message가 전송됩니다. 그러나 eyebeam의
경우는 계속적으로 DTMF tone을 전송하다가 버튼에서 손을 떼는 순간에 end message를 전송합니다.
Bypass의 경우에는 음성 코덱으로 압축하여 DTMF를 전송하고, 수신자 측에서는 동일한
음성코덱으로 디코딩하기 때문에, 디코딩 과정에서 DTMF가 오인될
가능성이 있지만, RFC2833의 경우는 DTMF를 payload type 101에
실어서 보내주고, 수신자 측에서 이 payload type 101을 찾아서 DTMF를 판별하기 때문에, DTMF가 유실될 확률(RFC2833은 UDP기반)은 있지만 잘못 판단될 수는 없다고 알고 있습니다.
Interface List 0x1 첫 번째 랜카드는 loopback 0x2 자신이 사용하고 있는 유선랜 카드 주소 0x3 자신이 사용하고 있는 무선랜 카드 주소
Network Destination 패킷이 전달될 네트워크 목적지 주소로서 Netmask와 AND연산을 한 후 패킷 목적지와 비교한다
Netmask Network Destination 을 구별하기 위한 서브넷 마스크로 사용된다 . 즉, 패킷 목적지에 Netmask와 AND 연산한다. 결국은 어떤 네트워크 목적지로 갈 것인지를 Netmask에서 결정한다.
Geteway 일반적으로 라우터를 말하며 인터페이스가 빠져 나간 패킷이 가야할 주소이다 .
Interface 네트워크목적지가 일치한 인터페이스로 패킷을 보내는것.
Metric 패킷의 생명력을 나타낸다. 목적지를 찾지 못하면 패킷은 루핑이 된다. 그걸 방지 하기 위해서 일정값을 지정해준다
간단히 각각의 항목에 대해서 알아 보았다. 이제는 routing 테이블을 알아 보자.
각 패킷이 어디로 가야 할지는 Network Destination과 Netmask를 AND 연산해보면은 어디로 가는지 알 수 있다.
참고로 테스트한 장비의 IP 설정 정보는 아래와 같다.
먼저 cmd 창에서 "route print"를 입력한다.
1. 빨간 박스
Network Destination과 Netmask를 AND 연산하면 0.0.0.0 이 나오는데,
이 줄의 의미는 목적지 컴퓨터가 다른 서브넷에 존재할 경우에 자신과 연결되어 있는 라우터로 신호를 전달하라는 의미이다. 다른 서브넷에 목적지 컴퓨터가 있다면, 자신의 랜카드를 통해서 게이트웨이로 패킷을 보내는 것이다. 즉 자신의 interface 102.90.10.19을 통해서 Gateway 102.90.1.1 로 전달하라는 의미이다.
2.
Network Destination과 Netmask를 AND 연산하면127.0.0.0 이 나오는데, 이 경우는 로컬 루프백 주소이므로 외부로 신호를 내보낼 필요 없이 내부적으로 처리하라는 이야기다.
3.
이것도 AND 연산을 하면 102.90.10.19가 나온다. 즉 자기가 자신한테 보내는 신호를 어떻게 처리할지를 나타낸다. 이 경우는 Gateway주소나 Interface 모두 127.0.01이다. 즉 목적지가 자기 자신이므로 외부로 신호를 보내지 않고 내부적으로 처리한다.
4.
AND 연산을 한 결과, 102.255.255.255 가 나왔다. 이 경우는 IP가 102.255.255.255인 경우 밖에 없다. 자신의 서브넷으로 보내는 broadcast 신호를 어떻게 처리할 지를 나타낸다. 이것도 그냥 자신의 네트워크 카드로 보내라는 의미이다.
5.
AND 연산을 한 결과, 224.0.0.0이 나왔다. 224.x.x.x는 D 클래스 주소로 멀티캐스팅용 주소이다. 이것의 의미는 멀티캐스트 신호를 어떻게 처리 할 것인지를 나타낸다. 멀티 캐스트 신호는 Interface 102.90.10.19을 통해서 Gateway 102.90.10.19로 전송하라는 의미이다. 즉, 그냥 자신의 네트워크 카드로 신호를 내보내라는 말이다.
6.
AND 연산을 한 결과, 255.255.255.255가 나왔다. 255.255.255.255는 브로드 캐스트 주소이므로, 브로드 캐스트를 어떻게 처리할 것인가에 대한 방법이다. Interface 102.90.10.19를 통해서 Gateway 102.90.10.19로 전송하라는 뜻이다. 즉, 자신의 네트워크 카드로 신호를 보내라는 말이다.
마지막으로 Persistent Routes에 대해서 알아보자.
뭐 영어의 뜻 그대로 영구적으로 설정된 라우팅 경로를 말하는 것이다.
일반적으로 랜카드가 하나일 경우에는 의미가 없음.
흠 route table 설정방법에 대해서 설명하려고 하였으나, cmd 창에서 route를 치니까 도움말이 나온다.
