I'm testing a concept so excuse the messy code, it's my first time really using pthreads at all. Running into a bit of a problem; it handles the first client that connects just fine, but none afterward. At first I thought it had something to do with my accept socket, because if I closed the accept socket after setting it to the socket in my thread's object, it would close the connection, so I made an array of accept sockets. Still not working.
In short, I don't want bitching about my coding style, etcetera, as I just threw this together to see how it works. It's most certainly not going to be used in anything; it's just a learning tool of sorts. If anyone can find where and why it's not working as I intend it to, I'd greatly appreciate an explanation.
>>6 This manual page explains the groff an.tmac macro package (often called the man macro package). This macro package should be used by develop- ers when writing or porting man pages for Linux. It is fairly compati- ble with other versions of this macro package, so porting man pages should not be a major problem (exceptions include the NET-2 BSD release, which uses a totally different macro package called mdoc; see mdoc(7)).
You really ought to be more specific.
Name:
Anonymous2008-10-13 17:41
If you're going to write sepples, do sepples, not mutant 'C'
This is a clusterfuck of non-whitespace characters. I can see what it's doing, but I don't want to know because it's so unintelligible. I want you to stop doing this. You are ignoring whitespace for her mentally retarded younger brother. I want you to stop doing that.
Love how you all comment on everything BUT the problem... you know, the exact thing I asked you not to do? I'm not looking for criticism on the writing style, etcetera. I know it's bad, I know how to improve it already. It's just some trash thrown together to try out pthreads. I'm trying to figure out why it's only handling the first socket and the first thread at a time. It almost seems as if something is blocking -- which, I've been led to believe, should not be the case with threads created using pthread_create()... and I don't see anything blocking other than listen and the accept loop in the main thread, and those are intended to.
>>2
As you can see, after the accept socket picks up a connection, it gets passed to a socket in the struct array. If I close the accept socket, it closes the connection that was passed as well, effectively closing both the accept socket and the socket in the struct.
The array of accept sockets was just for me to look at their behavior a little further. It doesn't really have a need here.
gtfo The Sussman, you're not an EXPERT BBCODE PROGRAMMER
Name:
22008-10-14 10:17
>>14 If I close the accept socket, it closes the connection that was passed as well
Retarded Windows behavior, whatever, but either way WHY WOULD YOU DO THAT. Stop blaming pthreads when your network code is so broken.
Name:
Anonymous2008-10-14 10:32
If you're going to use WinSock, why the hell are you using pthreads? Just use CreateThread(), your code isn't going to be portable anyway.
if I closed the accept socket after setting it to the socket in my thread's object, it would close the connection
...that's like pulling the phone cord out of the socket in the middle of a phone call.
Name:
Anonymous2008-10-14 10:39
...that's like putting too much air in a balloon.
Not really. In a proper socket implementation, received connections are in no way tied to the original listener.
Name:
Anonymous2008-10-14 12:39
OP, assuming you just want something with moderate throughput, rather than being industrial strength (for which you need messy asynchronous I/O constructs, or you write it in Erlang, like God intended), the structure you want is
Main listening thread -- a socket in a loop, blocking on accept(), ideally with time-wait as well to take the occasional look around to see if the process is shutting down
Connection threads -- when accept returns, pass the new socket into a thread that you spin off a new thread at that point with the socket as data, do your per-connection I/O in that (a select() loop is simplest, rather than trying to coordinate up-link and down-link on two separate threads), and when the connection is closes, just exit the thread procedure.
Things like thread-pooling are probably too cumbersome for the first learning exercise.
>>26
why are you assuming that your broken network code is irrelevant when trying to figure out why your program isn't working the way you expect it to?
Because it's as if the other threads don't even launch. If I put a printf before pthread_create and one at the start of the procedure it launches, it doesn't make it to the second printf the second time around.
>>28
Just use a single socket to listen for connections. Try checking the return code of bind in line 114 to see why using multiple listen sockets is a bad idea.
Name:
Anonymous2008-10-25 14:59
>>30
He's not using more than one listen socket. It also has the same behavior whether he has his accept socket array or not. Says so in the beginning.
>>30
Thanks. You're the only one to really give me any useful information so far. First thing I should've done was put in some error checking to try and catch this sort of thing. I'll poke around a bit more now.
Name:
332008-10-25 15:37
>>32
God you know there is a reason for a name field. It's so you can use it.
Needs a lot of cleaning up, but fixed that issue. Exactly what you said, issue with bind. I kept rebinding every time the loop iterated, and it failed because the address was already in use. Cut down now to an accept socket, a listening socket, and the client structure array's sockets.
>>35
So basically exactly what we've been saying all along, only you're too stupid to read.
Name:
Anonymous2008-10-25 16:53
>>36
No, exactly what you folks haven't been saying all along. The majority of what's been said was ridiculously vague or not concerning the problem at all. You've made it quite obvious that you're the one who's too stupid to read; your statement has no backing.
I was wrong in that it was my network code causing the problem, but that doesn't make everyone that said "LOLOL YOU SHOULD USE SOMETHING ELSE" or "LOLOL YOU SHOULD USE MORE C++ FUNCTIONS" or flat out didn't address the problem at all, right. Yes, someone finally said it was my broken network code - but that's too vague to be of much use. >>30 was the first to actually give me an idea of where things went wrong.
Note the following that either didn't help or were irrelevant:
>>42
And you were rebinding a listening socket because you were using multiple accept sockets. You just didn't understand >>2's answer until >>30 pointed out why using multiple accept sockets wouldn't work.
Name:
Anonymous2008-10-26 14:16
>>44
No, I was not rebinding a listening socket because I was using multiple accept sockets. I was rebinding a listening socket because it was inside a loop that it should have been outside of. If I put multiple accept sockets back in, it works fine; it's just redundant and useless.
>>43
Whiny douche? Why, because I, oh I don't know, like it when people actually mention something useful or relevant in reference to my questions? Troll harder, >>43.
Also, in reference to >>11 ... it's easily readable. Very easily. Unless you're dyslexic or something.
>>45
If you want useful and relevant answers try asking your questions on stackoverflow.com instead of /prog/ next time.
Name:
Anonymous2008-10-26 14:36
OP here, I can't program and should give up.
Name:
Bro2008-10-26 15:10
Bro, OP here, bro.
Name:
Anonymous2008-10-26 22:47
>>45
SAME PERSON AND YOU HAVE BEEN TROLLED CONSTANTLY
Whiny nutfucker, go to /pr/ if you want real answers. We masturbate all over our copies of SICP while currying Haskell nomads with SUAVE LISP TOADS here in /prog/.
Quit getting butthurt over the internet, it makes you look like you don't know what's going on.
Name:
Anonymous2008-10-26 23:30
>>50
I think you need to work on your meme lore, bro.