design question.
-
im trying to write a effective file sharing program. The program should brake down a file into pieces (byte[]) and send them over the network to the client. The client should then return a recipt or something, letting the sender know that he just recieved the byte[] then repeat. in the event the client never sends a recipt, the sender will then resend the previous byte[]. What im asking is, what is a efficient way and effective way of doing this. obviously hashcodes would need to be employed to ensure the client has recieved the correct data. any ideas/code examples on how to do this would be much appreciated. as it stands now i wrote a dll that automaticly deserializes (spelling),compresses,encrypts and sends it. the recieved does the oposite and then sends the newly formed object back. is there a easyier way of doing this? thnx, jesse The Code Project Is Your Friend...
-
im trying to write a effective file sharing program. The program should brake down a file into pieces (byte[]) and send them over the network to the client. The client should then return a recipt or something, letting the sender know that he just recieved the byte[] then repeat. in the event the client never sends a recipt, the sender will then resend the previous byte[]. What im asking is, what is a efficient way and effective way of doing this. obviously hashcodes would need to be employed to ensure the client has recieved the correct data. any ideas/code examples on how to do this would be much appreciated. as it stands now i wrote a dll that automaticly deserializes (spelling),compresses,encrypts and sends it. the recieved does the oposite and then sends the newly formed object back. is there a easyier way of doing this? thnx, jesse The Code Project Is Your Friend...
jtmtv18 wrote: im trying to write a effective file sharing program Depending on what you're trying to achieve, this is not easy. jtmtv18 wrote: The client should then return a recipt or something, letting the sender know that he just recieved the byte[] then repeat. Unless you're using UDP packets, there's no need on doing this. TCP assures that the connection is either dropped or the packet is received. jtmtv18 wrote: obviously hashcodes would need to be employed to ensure the client has recieved the correct data. Again, TCP assures that, and handle packet retransmissions automatically. Yes, even I am blogging now!
-
jtmtv18 wrote: im trying to write a effective file sharing program Depending on what you're trying to achieve, this is not easy. jtmtv18 wrote: The client should then return a recipt or something, letting the sender know that he just recieved the byte[] then repeat. Unless you're using UDP packets, there's no need on doing this. TCP assures that the connection is either dropped or the packet is received. jtmtv18 wrote: obviously hashcodes would need to be employed to ensure the client has recieved the correct data. Again, TCP assures that, and handle packet retransmissions automatically. Yes, even I am blogging now!
.NET Sockets is very poor, to say at best, it fails miserbly under load, sending packets in the wrong order... top secret
Download xacc-ide 0.0.3 now!
See some screenshots -
.NET Sockets is very poor, to say at best, it fails miserbly under load, sending packets in the wrong order... top secret
Download xacc-ide 0.0.3 now!
See some screenshots