Single p2p? Send files using sockets or remoting?

Single p2p? Send files using sockets or remoting?

• kpendoti

  Sorry I have to pass, if it was a Corporate/VC-backed capitalist project I'd pour my all into it... but it's not and I value my spare time. Good luck with your project, though.
  
  
  

• Vince12345

  but as you say remoting is better for lans and I want to make a p2p
  
  Would you join me to make an open source p2p in .net 2
  
  If so please add me to your msn   levalencia at gmail dot com
  
  

• Sql4088

  For your first question, it really depends on transfer sizes and number of conneced clients, available bandwidth etc. For example, if you're got dialup users you will want every last byte you can squeeze out of the network connection, and so you will want to go the sockets route and implement a very light transfer protocol (e.g. implement a syn/ack with a crc32 on small 2k packets).
  
  However, if we're talking a LAN environment you can expect to use remoting and still see transfer rates of 1MB/sec to 8MB/sec depending on performance, network latency, available bandwidth etc.  Remoting will tack on somewhere around 200-800 bytes depending on parameters (assuming you're using binary/tcp remoting, what I do is typically assume my calls have 400 bytes of overhead).
  
  Also, if you go the remoting route, you can pick up some 3rd party libraries (such as from www.genuinechannels.com) which have features such as compression available, Genuine Channels also offers a direct exchange manager (DXM) which makes implementing file transfers easier (leaving your 'communications channel' free while a 'dedicated' channel can handle one-way transfers).
  
  With remoting it's easier to pass a MBR-friendly stream wrapper to the receiving end and let the receiver read bytes out of the stream (by MBR-friendly I mean a stream wrapper than doesn't require the receiver to provide a buffer to write into, but instead has a simple Read() method that returns a byte[] to the caller, the size of the byte[] can be provided as a parameter or calculated over time based on call frequency (e.g. dynamically determine optimal packet size).
  
  I've done this a couple times, if you need some insight let me know. If you choose to implement file xfer via sockets you will be into writing a lot of code and half of it will be strictly protocol based (e.g. buffering data, determine packet start and end, producing a redundancy check to ensure the packet came in ok, writing additional logic to handle failure or cleanup at the client or server, etc etc).
  
  - Shaun
  

  
  
  
• Single p2p? Send files using sockets or remoting?