Thread: File Server Help

I'm sorry but I think I've done almost all you have told me.. what's wrong? I've been correcting every mistake I had, I only have some few silly mistakes in integer and long comparison and things like that, nothing related to recv and send.

Look, this is the server..

Code:

lautarox@lautarox-desktop:~/Escritorio/codigo c$ gcc -std=c99 -pedantic -Wall -Werror -Wextra fileserver.c -o fileserver
cc1: warnings being treated as errors
fileserver.c: En la función ‘passwdcheck’:
fileserver.c:38: aviso: comparación entre signed y unsigned
fileserver.c: En la función ‘recievefile’:
fileserver.c:80: aviso: se sugieren paréntesis alrededor de la asignación usada como valor verdadero
fileserver.c:84: aviso: comparación entre signed y unsigned
fileserver.c: En la función ‘main’:
fileserver.c:170: aviso: el puntero que apunta en el paso del argumento 3 de ‘accept’ difiere en signo // only this worries me, buty the connection is accepted, so.. this says that the pointer that points the third argument of accept differs from sign
fileserver.c:120: aviso: variable ‘j’ sin usar

Ohh that was really helpful, I'm really, really sorry of spending so much of you'r time, I'm really very thankful about your effort on making me understand everything..
I thought you said that the error on the select was the part where it looked if there was an error or it was not active..

Well, since the fd_sets are used with select, it might interfere with the way it works. I'd say that it probably would. But as to whether that's what is causing your problem I don't know, since I didn't bother to figure out what it did when it was broken, only why it wasn't doing what it was supposed to.

I don't mind spending time on this, just that you pay attention or ask specific questions when you don't understand is all.

edit: this isn't in response to the message just above this one.

Read these man pages:

man select
man select_tut
man recv
man send
man fork

There are also some networking web pages on a sticky in the networking forum.

The reason you have to receive chunks with select instead of the whole file at the same time is because select works on the principle of asynchronous communication. That means that information comes down the wire in chunks, and the program is free to do other things in the meantime. Another type of communication is synchronous communication. This is the type you use when you use blocking sockets, or fork or threads and blocking sockets. You basically stay until the connection is closed, and your program does not do anything else if it's waiting for data to come down the pipe. This is easier to code for, and you might want to do that instead, I don't know.

select pros:
highly scalable to large numbers of connections

select cons:
uses asynchronous programming model that can be difficult to code for if you don't already have an asynchronous model in your program.

fork pros:
provides program independence from other parts of the program. if one part crashes, the whole program doesn't have to go down with it.
fork can be used to have concurrent connections while still having a synchronous communication model, making programming easier.

fork cons:
heavyweight processes take up more resources than other alternatives. not as scalable to large numbers of connections.

threading with blocking sockets pros:
synchronous model with blocking sockets == programming easier
more lightweight than forks. Since you only have threads instead of processes, it doesn't take up as much resources.

threading cons:
can be difficult to code shared-data and inter-thread communications
not sure what else.

Well I think, I'll go for the hard way.. I'm thinking in a simplier function that creates a static struct (the static ones are the ones that remain after a function execution right?) with some info inside of it, total parts, parts in the moment, file name, etc and use the information to allocate the file contents.
I'll give it a try..

Originally Posted by lautarox

Well.. I've running some testing on the server and the client, and it was recieving the path and the parts, but no the "haslastpart" var, and now, don't know why, it's not recieving, even the path, I've modified the send and recv, so it has only one per send and recv, but I got to solve the problem with the select that's causing me all this trouble.
I took the select example from a chat server, that was on a webpage, and it worked perfectly, thats why I'm really confused too, the errors like the fwrite one and the accept were taken from the website..
What do you think it may be causing me problems inside the select?

Source code from the internet is not always the best example out there (yes, I am aware of the irony of that statement).

ok.... fix all the errors you know about. don't worry about the symptoms, because you already know you have errors. so get rid of all the double sends and fix the fd_sets and whatever else.

Well I think, I'll go for the hard way.. I'm thinking in a simplier function that creates a static struct with some info inside of it, total parts, parts in the moment, file name, etc and use the information to allocate the file contents.
I'll give it a try..

Ok. (I don't know what the hard way is, but I guess that's ok if you know)

I'd recommend some multiple of 2.. say 512 or so. But why do you want to know that? you're not going to send the whole file in one large send call. the send call only fills up the kernel buffer and then returns, however large that is, or however large the remaining space is. You don't know how much that is. So you'll have to get the return value of send and use it to calculate how much stuff has been sent and then continue from where it left off. Then you'll have to send it again, until it's all sent.

If you're using blocking sockets, then you would just put the send call in a loop and recalculate the start position for each call to send.

If you're using select in a loop, then you have to calculate the start of the next call to send and also make sure that socket is in the send fd_set for the next call to select.

Well.. I was thinking in multiple small parts to send the file, 512 bytes each part and allocate them where they belong and how you said, checking if it has sended the correct ammount of bytes.. what do you think of that?
What about the for and the i var there?

Don't store the whole file in memory. Instead, do it bit by bit like this:

server:
recv 512 (or less) bytes from socket into buffer
save buffer into file
recv 512 (or less) bytes from socket into buffer
save buffer into file
recv 512 (or less) bytes from socket into buffer
save buffer into file
recv 512 (or less) bytes from socket into buffer
save buffer into file

client:
recv 512 (or less) bytes from socket into buffer
save buffer into file
recv 512 (or less) bytes from socket into buffer
save buffer into file
recv 512 (or less) bytes from socket into buffer
save buffer into file
recv 512 (or less) bytes from socket into buffer
save buffer into file

Originally Posted by lautarox

And can something like this be done in c?

Code:

for(i=0;i<max;i++) {
i.id = 1;
}

No. What are you trying to do?