| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11
Comments:
<0> would it be better to do multi threadeing and create a thread for msg processing?
<0> or placebo affect
<1> A couple threads is good if you have hundred or thousand sockets, but don't make the error of launching one thread per socket
<1> Stick to non-blocking and select()
<0> k
<2> introducing threads takes your current level of pain and multiplies it by ten.
<2> you need to take that product, and compare it to your pain threshhold.
<1> Eheh :)
<2> sometimes people overestimate the amount of pain they can endure, so i recommend stabbing yourself in the chest a few times to get a feel for it.
<3> hey anyone fluent in opening fd's in shell scripts and sending content through them?
<3> Maloeran, avoid select(), if you're on unix systems, use epoll.
<0> epoll?
<2> Gambit-, with exec?
<0> wtf is that
<3> AaronWL, I don't know how to do it, tbh, but yeah, I think with exec.
<3> kthx^, it's a linux kernel 2.6 ism
<3> calc c10k
<1> I know, Gambit-, but the suggestion was for kthx^
<4> Ten thousand clients simultaneously -- an analysis of the problem: http://www.kegel.com/c10k.html
<2> i dont remember offhand either, but yeah, exec
<2> the bash manual says how
<0> isnt poll slower than select?
<2> select() and poll() are algorithmically identical. dont expect a big difference either way.
<3> kthx^, /epoll/ is probably the fastest one around.
<3> epoll != poll
<0> :O
<2> select() should be used over poll() primarily because select is more portable.
<3> check out libevent if you're going crossplatform
<2> personally, id do with select, but keep your code open to upgrading to something better if you need it.
<3> straight select() should be generally avoided nowadays. If you're on unix, use epoll, if you're on windows, use iocp.
<0> <= likes ot keep it simple
<1> select() is fine when enough
<2> only seriously high performance stuff, and only then in special cases, needs something better than select()
<0> iocp? wtf is that
<3> kthx^, IO Completion Ports.
<2> iocp is a win32 asynch socket notifiation mechanism
<0> :O
<5> I'm afraid of IOCP
<2> it is superior to select(), in general.
<5> Absolutely
<5> Gambit- wha?
<3> There's no good reason to use select() when you could be using epoll.
<0> like WSAAsyncSelect() ?
<2> Gambit-, portability
<5> kthx^: Better
<0> :O
<3> AaronWL, then use libevent or ACE.
<1> Don't worry about it, kthx^, I don't think you are writing high-performance large scale server software
<0> its an ircd
<0> :(
<2> select() is more portable than libevent or ACE
<3> AaronWL, shows what you know -- libevent /uses/ select if necessary, but also uses the more powerful systems if they're available.
<2> ircd is one of the cases where, in high load situations, epoll or similar will outperform select()
<2> Gambit-, right, but there is almost certainly considerable work adapting libevent to an operating system it doesnt support well already.
<3> AaronWL, the bash manpage is so useless for practical examples.
<2> and also considerable work adapting it to your app.
<2> select() is absolutely universal among modern network impls.
<3> AaronWL, there shouldn't be, since if it support select() in the first place, then libevent should work in it, but tbh I don't bother with large scale cross-platform functionality.
<3> AaronWL, not true at all
<3> AaronWL, most embedded OS's don't support it (vxWorks, for example)
<2> you find me a network impl without select(), and.. well.. :)
<2> well, all of the bsd derivatives do
<3> well duh :)
<3> there's a reason it's called berkely sockets :)
<2> what sort of sockets are you using that aren't bsd?
<3> vxWorks, iirc
<6> jeffloc, let me know when you're around again.
<5> SOCKET!
<2> well, in that case, none of his code will work anyway
<3> any sort of non-BSD network stack implementation.
<7> daxxar, are you going?
<3> Yeah, that's why I'm saying that the portability argument isn't really a good one :)
<7> I'm just doing that example
<2> select() will always work if his other code work, with very little pain.
<7> if you want it
<6> jeffloc, nope.
<2> libevent almost certainly requires more pain, and will cause more complications, and more bugs, and large tarball or more dependencies, and whatever other crap
<3> but anyways, kthx^, take a look at that website I tossed up and make your own decision. You won't go horribly wrong with select, it's just not optimal for *nix platforms.
<6> jeffloc, nope - I'm not going, yes - I want it. :-)
<7> ok
<3> AaronWL, you haven't looked at all at libevent, have you :)
<2> select() fails mainly in the case where you have many idle connections.
<2> Gambit-, peripherally, as part of researching into general multiplexing.
<1> select() is poor when handling very high counts of sockets
<2> ive never applied it.
<2> Maloeran, only if most are idle.
<8> bugs bugs
<7> it'l just be a program that sends a udp packet to a bound port on 127.0.0.1 then replys it
<2> if most sockets are active, select() is just fine.
<5> Maloeran yeah well you can handle only like 32 at once usually pre thread anyway, right?
<5> *per
<2> consider, even, the amount of time it takes to iterate to 65535 is trivial compared to the other processing a busy server will need to do
<1> What? :) There's no such thing as a per-thread limit...
<2> the main problem is when you have 10k connections, but only 10 are active.
<2> on algorithmical grounds, select() is inferior to any O(1) algorithm, but in practice, select() almost always exceeds the performance of other parts of your server.
<8> love love?
<9> the channel key for #c definitely is a nice one ...
<1> binrapt, FD_SETSIZE tends to be 1024 or 4096 or so. As I said, select() is a problem for very high counts of sockets...
<5> 64 here :p
<9> 64 ?
<5> FD_SETSIZE == 64
<9> what are you programming there on, your watch ?
<5> Windows XP
<1> That's pathetic
<2> FD_SETSIZE is modifiable, as on most unixes
<9> bill doesn't select, he takes all
<2> just define it to whatever size you'd like.
<5> Ah, I see.
<2> the default size is just a default.
<1> But 64 file descriptors per process? That's almost like a sad joke
<9> default 64 is still odd ...
<2> it corresponds with some other related win32 constant, so it made sense at a the time
<2> and on the old winsocks, that was the maximum system-wide tcp connects yuo could have
<9> winsocks :)
<5> Open sores feg alert
<9> i still remember the times, connection over your 14.4 modem, starting up hyperterminal .. then winsock ownage and wooho, netscape 3 gold here i come :)
<2> back in the day on windows, there was a 16-bit winsock vs 32-bit winsock thing
<2> i never really understood all of that, but the 16-bit winsocks ****ed really bad and didnt work with a lot of apps
<2> but if thats what your isp gave you, you were screwed.
<9> hehe ... i used an university account back then ...
<9> but still, netscape 3 gold owned when you compared it to mailing & gopher :)
<9> arj-ing together the 100 pieces you got as an answer into your mailbox ... i'm about to start crying over here :p
<2> yeah, when i started using the internet, www was just catching on.. most of the web was gopher
<2> its too bad about gopher.. i dont even know if its usable these days.
<9> gopher worked ... and didn't have flash or popups ...
<2> i tried to use gopher a few years back.. i couldnt nagivate worth crap
<2> supposedly some people are still running gopher servers, but i think the main heirarchy is screwed
<6> Hm, brb jeffloc, taking lunch.
<7> got called away
<7> won't be much longer
<9> imagine downloading a dvdrip over gopher ...
<9> here is part #1234234141423
<9> :p
<2> plus its not 8bit clean..
<2> and probably not even 7bit clean
<2> i dont remember gopher being especially slow though.
<9> should take around 700 hours over 14.4 modem ... if 8 bitted :p
<0> calc iocp
<4> what is foo ?
<9> i guess the dvd will make it sooner into the store ...
<9> and that amount of calltime ... buying would be cheaper
<2> iocp is often confused with iocr's
<0> mean iocp doesnt require loops like select </3
<2> iocp is really only for fairly serious high performance stuff
<2> iocr is better for general use, imo.
<0> iocr
Return to
#c
or
Go to some related
logs:
#nhl
*thismight.be/offensive/*
heyh saidi
mechillen
#sql
#worldcup
#heroin
#beginner
#nintendo
how to train a 8 year old to play soccer
|
|