Hi Shachar, can you please give more detailed explanation why a thread per socket is not a wise idea? Not that I'm in a hurry to impplement this way, but I'll give you an example where I thought this could be a solution for me. One of the requirements of my project asks that my application, when it is a client, will actually make "endless attempts to connect" some of the servers, until any of the servers comes alive and the connection is established. (an interesting subject of it's own, which to one problematic ussie of this, I'll relate further below.) You probably agree that this caanot be done form the main thread. I ended by implementing a thread just for this. Attempting to connect endlessly until the connection is established and exits while raising a flag which the main thread checks just before each select to add the appropriate file descriptor to the select/poll array of descriptors. However, I do ask myself what's wrong in creating a thread per socket? In this thread I could try to connect, which in case it does not connect whould not disturb any other thread and when connected, would continue to oerate concurrently with the other threads. So, yyes, please explain what could be unwise in such an implementation. Concerning the endlss loo of connect(), a person on the remote computer told me that when a server is not alive there, those endless connects stuck the computer and his only way to free it is by unplugging the ethernet wire. Upon replugging it, everything works again. So, I'm ask to "sleep" for some seconds between each attempt to connect. Can you the experienced people coment on this? Is this event a known one and would indeed the delay of some seconds solve this? Or the reason to this event is something else? Thanks, Rafi.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shachar Shemesh Sent: Tuesday, May 15, 2007 8:14 AM To: Amos Shapira Cc: Linux-IL Subject: Re: need some help with tcp/ip programming Amos Shapira wrote: > > in neither case will read return 0. the only time that read is allowed > to return 0, is when it encounters an EOF. for a socket, this happens > ONLY if the other side closed the sending-side of the connection. > > > Is there an on-line reference (or a manual page) to support this? man 2 read > From what I remember about select, the definition of it returning a > "ready to read" bit set is "the next read won't block", which will be > true for non-blocking sockets any time and therefore they weren't > encouraged together with select. I believe you two are talking about two different things here. There is a world of difference between UDP and TCP in that regard. UDP is connectionless. This means that read's error codes relate only to the latest packet received. UDP also doesn't have a 100% clear concept of what "CRC"/"checksum" actually means. I still think it's a bug for "select" to report activity on a socket that merely received a packet with bad checksum (there is no CRC in TCP/IP), as how do you even know it was intended for this socket? In TCP, on the other hand, a read is related to the connection. Packets in TCP are coincidental. Under TCP, read returning 0 mean just one thing - the connection is close. > > if you have so many connections that multiple threads will become a > problem then a single thread having to cycle through all these > connections one by one will also slow things down. No, my experience begs to differ here. When I tested netchat (http://sourceforge.net/projects/nch), I found out that a single thread had no problem saturating the machine's capacity for network in/out communication. As long that your per-socket handling does not require too much processing to slow you down, merely cycling through the sockets will not be the problem if you are careful enough. With netchat, I used libevent for that (see further on for details), so I was using epoll. Your mileage may vary with the other technologies. > Not to mention the signal problem and just generally the fact that one > connection taking too much time to handle will slow the handling of > other connections. Yes, it is probably better to use a single thread that does the event waiting, and a thread pool for the actual processing. Having one thread pet socket, however, is not a wise idea IMHO. > A possible go-between might be to select/poll on multiple FD's then > handing the work to threads from a thread pool, but such a job would > be justifiable only for a large number of connections, IMHO. It's not that difficult to pull off, and I believe your analysis failed to account for the overhead of creating new threads for each new connection, as well as destroying the threads for no longer needed connections. > If you insist on using a single thread then select seems to be the > underdog today - poll is just as portable (AFAIKT), and Boost ASIO > (and I'd expect ACE) allows making portable code which uses the > superior API's such as epoll/kqueue/"dev/poll". Personally, I use libevent (http://www.monkey.org/~provos/libevent/), which has the advantage of being a C linkage program (ASIO is C++, as is ACE). It also has a standard license (three clause BSD). I skimmed over the boost license, and it doesn't seem problematic, but I don't like people creating new licenses with no clear justification. Shachar ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.0/803 - Release Date: 5/13/2007 12:17 PM ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
