*** New Software: UDP File Transfer Commercial Edition ***

Hi,

UDP File Transfer Commercial Edition is a tool to transfer large files from
one computer to another computer using internet technology.

The software can be freely downloaded from Skybuck's website.

In demo mode:

+ Receiving files is possible.

+ Sending files is possible but the file's content will be garbled.

In full mode:

+ Receiving files is possible

+ Sending files is possible.

To switch to full mode one can buy an activation code online from the
webstore

The software is located at:

http://www.mycgiserver.com/~skybuck

Have fun

Bye,
Skybuck.

LOL - ever heard of FTP?

What else does your tool transfer from the hard disk? Buyer
beware!!!!!!!!!!!!!!!!

"Skybuck Flying" <(E-Mail Removed)> wrote in message
news:bqs8en$100$(E-Mail Removed)...
> Hi,
>
> UDP File Transfer Commercial Edition is a tool to transfer large files
from
> one computer to another computer using internet technology.
>

<snip>

The tool is still under active development.

It already has many properties which makes it better than FTP.

CRC32 checksums

AES encryption

192 Bit Tiger File hash.

Just to name a few

"News Account" <(E-Mail Removed)> wrote in message
news:czjAb.1213$2S4.1070@fe10...
> LOL - ever heard of FTP?
>
> What else does your tool transfer from the hard disk? Buyer
> beware!!!!!!!!!!!!!!!!
>
> "Skybuck Flying" <(E-Mail Removed)> wrote in message
> news:bqs8en$100$(E-Mail Removed)...
> > Hi,
> >
> > UDP File Transfer Commercial Edition is a tool to transfer large files
> from
> > one computer to another computer using internet technology.
> >
>
> <snip>
>
>
>

Skybuck Flying wrote:

> The tool is still under active development.
>
> It already has many properties which makes it better than FTP.
>
> CRC32 checksums
>
> AES encryption
>
> 192 Bit Tiger File hash.
>
> Just to name a few

Ever hear of scp?

Here's some info, from the Linux man file


DESCRIPTION
scp copies files between hosts on a network. It uses ssh(1) for data
transfer, and uses the same authentication and provides the same security
as ssh(1). Unlike rcp(1), scp will ask for passwords or passphrases if they
are needed for authentication.

Any file name may contain a host and user specification to indicate that the
file is to be copied to/from that host. Copies between two remote hosts are
permitted.

The options are as follows:

-c cipher
Selects the cipher to use for encrypting the data transfer. This option is
directly passed to ssh(1).
-i identity_file
Selects the file from which the identity (private key) for RSA
authentication is read. This option is directly passed to ssh(1).

etc.

--

Fundamentalism is fundamentally wrong.

To reply to this message, replace everything to the left of "@" with
james.knott.

"James Knott" <(E-Mail Removed)> wrote in message
news:4WjAb.131572$(E-Mail Removed) able.rogers.com...
> Skybuck Flying wrote:
>
> > The tool is still under active development.
> >
> > It already has many properties which makes it better than FTP.
> >
> > CRC32 checksums
> >
> > AES encryption
> >
> > 192 Bit Tiger File hash.
> >
> > Just to name a few
>
> Ever hear of scp?

Yes a little bit.

>
> Here's some info, from the Linux man file

Unfortunately I don't use linux.
>
>
> DESCRIPTION
> scp copies files between hosts on a network. It uses ssh(1) for data
> transfer, and uses the same authentication and provides the same security
> as ssh(1). Unlike rcp(1), scp will ask for passwords or passphrases if
they
> are needed for authentication.

Yes scp is based on TCP. TCP itself has weak checksums and TCP can be slow
over wireless networks and even gigabit networks because of various reasons.

My tool however uses the UDP protocol and it's own algorithms and protocols
which remain secret for the time being.

These protocols have been designed to achieve higher and more reliable
performance than TCP.

I believe that my tool is ready for the future ( gigabit networks and
wireless networks ).

The current implementation is of average speed.

On a pentium 166 with encryption and checksums and tiger hash enabled it
achieves 200 kilotebyte/sec at the moment over a 10 megabit network. TCP
achieves 500 kilobyte/sec.

However pentium 166's mhz are old technology. I'll bet most users have a
Pentium 4, 2000+ mhz.

So I think my tool might achieve higher performance on these kind of
computers.

It would be great if someone could test my tool on this kind of setup and
report the speed:

Pentium 4, 2000+ mhz <---- 100 or 1000 megabit connection ----> Pentium
4, 2000+mhz

I would not be surprised if on such a setup it would achieve the maximum
harddisk write speed, which is about 4 MB/sec for an average harddisk.

>
> Any file name may contain a host and user specification to indicate that
the
> file is to be copied to/from that host. Copies between two remote hosts
are
> permitted.
>
> The options are as follows:
>
> -c cipher
> Selects the cipher to use for encrypting the data transfer. This option is
> directly passed to ssh(1).
> -i identity_file
> Selects the file from which the identity (private key) for RSA
> authentication is read. This option is directly passed to ssh(1).

RSA could be interesting to implement as an extra option for establishing a
symetric key.

However I do think that RSA is not ultra safe. I think it is vunerable to
man-in-the-middle attack.

Skybuck.

["Skybuck Flying"]

| Yes scp is based on TCP. TCP itself has weak checksums and TCP can be slow
| over wireless networks and even gigabit networks because of various reasons.
|
| My tool however uses the UDP protocol and it's own algorithms and protocols
| which remain secret for the time being.
|
| These protocols have been designed to achieve higher and more reliable
| performance than TCP.

Ah, you're going to reinvent a "better" TCP. Good luck, lots of people
have tried to do this. Meanwhile, I'll stick with TCP and applications
like scp.

| I believe that my tool is ready for the future ( gigabit networks and
| wireless networks ).
|
| The current implementation is of average speed.
|
| On a pentium 166 with encryption and checksums and tiger hash enabled it
| achieves 200 kilotebyte/sec at the moment over a 10 megabit network. TCP
| achieves 500 kilobyte/sec.

A Pentium-166 with a decent operating system (e.g. FreeBSD) can saturate
a 100 Mbps Ethernet link.

Steinar Haug, Nethelp consulting, (E-Mail Removed)

"Steinar Haug" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> ["Skybuck Flying"]
>
> | Yes scp is based on TCP. TCP itself has weak checksums and TCP can be
slow
> | over wireless networks and even gigabit networks because of various
reasons.
> |
> | My tool however uses the UDP protocol and it's own algorithms and
protocols
> | which remain secret for the time being.
> |
> | These protocols have been designed to achieve higher and more reliable
> | performance than TCP.
>
> Ah, you're going to reinvent a "better" TCP.

Hmm, not going, did.

> Good luck, lots of people have tried to do this.

0.01% luck, 10% inspiration, 30% research, 30% practice, 10% brains and
19.99% transpiration lol.

> Meanwhile, I'll stick with TCP and applications

Sounds like you have no other choice on FreeBSD to bad.

> like scp.
>
> | I believe that my tool is ready for the future ( gigabit networks and
> | wireless networks ).
> |
> | The current implementation is of average speed.
> |
> | On a pentium 166 with encryption and checksums and tiger hash enabled
it
> | achieves 200 kilotebyte/sec at the moment over a 10 megabit network.
TCP
> | achieves 500 kilobyte/sec.
>
> A Pentium-166 with a decent operating system (e.g. FreeBSD) can saturate
> a 100 Mbps Ethernet link.

It's not the operating system at fault. It's TCP at fault. There are
documents about that.

TCP can only saturate for 33% to 40%.

People have reported my UDP Speed Test tool to achieve good speeds at 99%
saturation.

The goal has been set

--
UDP File Transfer Commercial Edition available at:
http://www.mycgiserver.com/~skybuck

>Yes scp is based on TCP. TCP itself has weak checksums and TCP can be slow
>over wireless networks and even gigabit networks because of various reasons.

UDP can be a hell of a lot slower than tcp (in your application anyway) - if a
udp packet looses it's way (which it will do at some point), it'll have to be
resent from the beginning again - after the other end has told the source it has
missing data.

If your data MUST get thru (unlike audio, video etc), then UDP is ok if you have
no packet loss, else things will start to slow down.

>On a pentium 166 with encryption and checksums and tiger hash enabled it
>achieves 200 kilotebyte/sec at the moment over a 10 megabit network. TCP
>achieves 500 kilobyte/sec.

Doesn't that mean your UDP implementation is less than half the speed of TCP ?

>However pentium 166's mhz are old technology. I'll bet most users have a
>Pentium 4, 2000+ mhz.

You wish !

Packet loss is going to be your problem, not pooter speeds.

Clive

>It's not the operating system at fault. It's TCP at fault. There are
>documents about that.
>
>TCP can only saturate for 33% to 40%.
>
>People have reported my UDP Speed Test tool to achieve good speeds at 99%
>saturation.

You saturate a network, and you'll have a ton of people come down on you.

Gaps have to be left on networks to allow for other stations to jump in with
their own packets to send somewhere - you stop this happening and you'll have
some very unhappy people looking in your direction, not that the network wud let
you do it anyway (if it's configured correctly).

Networks are for sharing don't forget.

UDP will increase the amount of bandwidth needed, ie, if a tcp packet gets
dropped/lost, then it is only sent again on one particular hop. However, if a
UDP packet is lost, it has to be resent from the very beginning - so using
bandwidth up on ALL hops along the way thru the network (till it gets lost
again) - etc etc.

If lost data can be tolerated (audio etc), then UDP is the way to go.

If lost data cannot be tolerated, then UDP is NOT the way to go, due to the
retry problem as above (more bandwidth used).

Clive

"Skybuck Flying" <(E-Mail Removed)> wrote in news:bqssmd$l5o$1
@news3.tilbu1.nb.home.nl:

>> Ah, you're going to reinvent a "better" TCP.
>
> Hmm, not going, did.

I'm sure you did... whether the world will accept it is a different story

: ) : ) : )

--
Lucas Tam ((E-Mail Removed))
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/