thank you guys, i'll try with the ideas u mentioned, some other questions regarding my situation.
in my client it has to have a socket opened for days.(reason is this host-an embedded device- takes quite lot of time to init the socket so for a real time thing it won't work to init sockets each time) can a TCP/IP socket do this. i.e. keep the socket conected without hanging up? it has to do the same thing(send files) within the same socket at different times. can it be done? by sending a starting sequence each time a new file is sent will work? anyway, how can i decide a proper starting seq since it should be not in the sending packet? i'm sending a jpeg file. indika --- In [email protected], "Nico Heinze" <[EMAIL PROTECTED]> wrote: > > --- In [email protected], "Indika Bandara" <indikabandara19@> > wrote: > > > > here are my requirements > > > > very very simple indeed ! > > > > client: > > send filename > > send filesize > > send file > > > > server: > > read fixed lenght of filename, filesize > > allocate space for file > > store file > > send some command back > > > > these tasks work fine on my loopback interface. since TCP > > doesnt lose them in a real network, hope i can assure that > > it works > > > > i use unsgined char buffers to read. > > > > eg. > > unsigned char *buffer=new unsigned char[size]; > > bzero(buffer,size); > > > > i receive the files correctly. > > > > do i have to send starting/ending sequences to mark the > > start/end of packets. > > > > for example. > > after creating socket and calling connect(); > > > > i call at client > > write(10 bytes); > > write(15); > > > > then at server i call > > read(10); > > read(15); > > > > will i get what i send? will the server not read any garbage? > > Indika, > > don't worry, TCP/IP will handle these issues for you. But -as usual > with read() and write()- you should always check that the amount of > bytes you receive during one read() call equals the amount of bytes > you expect. > So, in order to create a fairly reliable protocol, you should always > encapsulate the data (be it a protocol command or a single block of > data or whatever) in a packet that you can check for errors yourself; > for example, use the first four bytes (in a clearly defined order!) to > transfer the actual length of a block of data; after these four bytes > only send the actual data to transfer. So you will have to implement > two read()s: > > 1) if (read( fd, & Length_Buffer, sizeof( Length_Buffer)) != 4) > { perror( "reading length bytes"); > exit( EXIT_FAILURE); > } > 2) after you have converted the four bytes stored in Length_Buffer to > a size_t value (let's name it Length), do this: > if (read( fd, & Buffer, Length) != Length) > { perror( "reading actual contents"); > exit( EXIT_FAILURE); > } > > and so on. I hope you understand the general picture. > > I suggest that you always exchnge data between server and client in > two distinct packets (and every packet should have its length > prefixing it, as mentioned above): > a) Example send data from client to server: the first packet sent from > client to server is a command packet, the server responds with an > acknowledgement packet; the second packet from client to server > contains the actual data plus a checksum (just for the paranoid); the > second packet from server to client is a response indicating whether > the checksum fitted or not. > b) Example receive data from server at client: the first packet sent > by the client is a Send request; the server then sends two packets, > first an acknowledgement (or a "I refuse!" packet in case the file is > not available on the server), the second contains the actual file plus > a checksum; the second packet from the client to the server then > states whether the file was received and whether the checksum was correct. > c) Example terminate connection: the client sends a packet to the > server, the server sends a packet back indicating whether it will > terminate the connection or not (if not, maybe with an indication as > to why it refuses to close the connection). > > I hope you understand what I mean. If not, please ask again. > > Regards, > Nico > To unsubscribe, send a blank message to <mailto:[EMAIL PROTECTED]>. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/c-prog/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
