Re^3: Trapping socket error in client when server goes away

Thx thospel, that seems to do the trick.

BTW, as this is all on the same machine ie client+server, would UNIX socket be faster than local INET? Just wondered whether the fact there's a disk file for UNIX socket slows it down?

The proj handles packets from a busy RADIUS server, so speed is of the essence...

Comment on Re^3: Trapping socket error in client when server goes away

Replies are listed 'Best First'.
Re^4: Trapping socket error in client when server goes away by thospel (Hermit) on Oct 20, 2004 at 03:45 UTC
Yes, UNIX sockets will be faster. No, the disk access won't slow it down. The filesystem basically just provides a namespace for the sockets, so it's at most an initial inode lookup at. And you can get rid of even that potential disk access by putting the socket in a memory based filesystem. Systems like linux even provide abstract unix domain sockets that are anonymous (well they exist in a backing virtual filesystem), and these are nowadays supported in perl. This kind of disk access isn't something to worry about anyways on busy servers. Due to it being busy, the information will normally be cached in memory, so no actual disk access takes place (well, sometimes for atime updating, but that can be turned off and is usually write-behind anyways). But if you wanted extreme speed, you probably shouldn't have chosen perl in the first place. The processing you'll do will normally swamp this kind of detail. First write a clear well working program, and only when it turns out to be too slow, profile and start optimizing only the slow parts. Don't start guessing too early and destroy the cleanness of your program. (to give an order of magnitude, on a somewhat modern processor you should be able to handle a few 1000 protocol roundtrips per second in perl)	[reply]

Replies are listed 'Best First'.

Re^4: Trapping socket error in client when server goes away
by thospel (Hermit) on Oct 20, 2004 at 03:45 UTC

No, the disk access won't slow it down. The filesystem basically just provides a namespace for the sockets, so it's at most an initial inode lookup at. And you can get rid of even that potential disk access by putting the socket in a memory based filesystem. Systems like linux even provide abstract unix domain sockets that are anonymous (well they exist in a backing virtual filesystem), and these are nowadays supported in perl.

This kind of disk access isn't something to worry about anyways on busy servers. Due to it being busy, the information will normally be cached in memory, so no actual disk access takes place (well, sometimes for atime updating, but that can be turned off and is usually write-behind anyways).

But if you wanted *extreme* speed, you probably shouldn't have chosen perl in the first place. The processing you'll do will normally swamp this kind of detail. First write a clear well working program, and only when it turns out to be too slow, profile and start optimizing *only* the slow parts. Don't start guessing too early and destroy the cleanness of your program. (to give an order of magnitude, on a somewhat modern processor you should be able to handle a few 1000 protocol roundtrips per second in perl)

[reply]