Greetings All,

Can you some one throw some light on the problem, I am experiencing.

I have a server that periodically(120 Hz) sends a packet to client.

If I manually kill (SIGKILL) the client application, the server applications exits. Any way I can prevent the server from exiting ?

Client is connected to server on a TCP socket. If I do same experiment with UDP socket, the server does not exit when the client is killed.

Interesting problem. I think you will have to be much more specific before anyone attempts an answer

which server/client/versions/distros/etc? How is the server started? Xinetd/inetd/something else?
Is it dark net/encrypted/firewalled/redirected in any way that might affect behaviour?

How come you can send tcp and udp packets to the same server?

Well business_kid is definitely correct we need a lot more info on this. However I would suggest it might have something to do with TCP actually making a connection and UDP being connectionless. When what ever service you are running notices the connection ending, it stops listening. UDP is probably not sending a close signal on exit to the service so it stays open.


What is the name of the service you are running?

Travis

Hello Business_Kid,

Well the server program is my program, I setup the socket as a stream socket, do a bind and pend on accept. Client then connects to the server socket, server program then starts doing send() at 120 hz. (120/second). Client receives the data, processes it fine. But as soon as I kill the client program, It kills the server program too.

My linux version is 3.9.0 for git tree.

My HW is a embedded target, so I start 2 seperate programs doing tcp and udp, and same thing on the client side.

All proprietary stuff, eh? Embedded, eh? There is no valid reason why a 'broken pipe' type error should result in a server crash. It might result in a server instance crash. I would check what signals are being received/sent.

How does your server react to a packet that starts but never finishes? If, otoh, you set the client to send 20 packets and then stop, it will complete the 20 packets. and then close the connection.

It's in the source.

1 members found this post helpful.

Thanks business kid for the insight. What I also experience is, lets say I open up a ssh connection from target which is server to a target which is client, and if I do cat on a very large file (client file), I get broken pipe too. Can this be a driver type issue ? Client server targets talk to each other on a Marvell switch.

I am a hardware guy myself.

At this distance, it could be anything. Take nothing for granted; don't go swapping stuff randomly. Let facts and debug info lead you. To solve this, someone is going to have to be there with the equipment. At the moment, it's you.

UDP effectively connectionless (though perhaps "sessionless" would be a better adjective).
There is no facility to ask for a re-transmit (ARQ) or even packet accounting, which is why it's normally used for streams where the next packet is always more important than the last (stock market tickers, live feeds, etc).
TCP carries the extra accounting overhead, but at the adapter level that accounting is causing things like ACK, SYN and ARQ passing back and forth. The ARQ has a timeout value, either I get this by <time> or the session closes. UDP does not.
It's a WAG, but I'd start there.

i think it mite have something to do with (for e.g.) the ssh daemon forks a new process for each new connection whereas a daemon-less service mite establish one connection and then exit when the client hangs up (e.g.):