Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Passing Files

22 views
Skip to first unread message

BeeJ

unread,
Apr 19, 2013, 10:08:55 PM4/19/13
to
I want to pass image files between several PCs. Several XP Pro and Win
7 Pro PCs. This will be automatic with no user initiated send.

So I might have a VB6 app on each PC that would transmit and/or receive
the file. One option would be to use IP addresses; however, IP
addresses change on my local network. e.g. I have had to set a fixed
IP on my printer because the router would change IP addresses around
from time to time. Is there a way to get the PC name remotely so I can
reference that and/or convert to an IP address to use to transmit the
image file?

Is there a better way to do this? Let's leave out Windows shared
folders for the moment since one or more PCs might not have that set up
or might not want that exposure.


Phil A

unread,
Apr 19, 2013, 11:04:58 PM4/19/13
to
use computer name. it is always right whether it 's dhcp or fixed.


"BeeJ" <nos...@spamnot.com> wrote in message
news:kkst69$f7t$1...@dont-email.me...

Jim Mack

unread,
Apr 20, 2013, 7:27:47 AM4/20/13
to
Since you're writing the apps on all the PCs, you can control how they
discover each other. You don't say what the architecture of the system
is, so it's hard to know the best method, but in a general case where
the PCs are all peers in a common subnet, you could use a simple scheme
of having each one announce itself (by IP) by broadcasting a small UDP
packet that the others are listening for. Each PC can then keep a list
of who's around.

This can happen as a sort of heartbeat, so when a PC drops off or joins
up, the membership list will be updated within a couple of beats,
whether that's every 5 minutes, every second, whatever you choose.

--
Jim

BeeJ

unread,
Apr 20, 2013, 10:41:04 AM4/20/13
to
Let me clarify a little since I am now discovering a few things here.

I have an app the gets the HostName and returns information on the
connections on the network.

So it does discover another PC but I am not sure what the IP address is
that it is returning. My base IP is 192.168.3.X.
According to another commercial app the IP of one of the PCs is
192.168.3.1 but the HostName of the other app says it is
192.168.192.101.

After a few cycles that PC does not appear in the list again. Not sure
why that happens.

Based on what little I know I need to talk on the network to the
correct IP and some port number. The receiving app looks at the same
port number for incoming. I know that certain port numbers are
assigned. Is there a set of port numbers that are appropriate for my
use or do I just pick?

What I think I need is code that scans the 192.168.3.x range and
reports who that is. Is there an API that I can use to do this?


Henning

unread,
Apr 20, 2013, 12:53:57 PM4/20/13
to

"BeeJ" <nos...@spamnot.com> skrev i meddelandet
news:kku98h$4m8$1...@dont-email.me...
Why not follow the advice to use the computer name? As for the
192.168.192.101, some (app) has moved it to another network. Depending on
the Network Mask it most likely is out-of-reach. No need for the IP, just
use the HostName and Port#.

/Henning



BeeJ

unread,
Apr 20, 2013, 2:03:38 PM4/20/13
to
Henning formulated the question :
Yes, but I am trying to understand how to get the hostnames into a pick
list.
So from what I am beginning to understand, I scan IPs in the range of
192.168.3.x and list those and their host name. Need to know how to do
this. Or is there another way to gather active hostnames directly?
From what I have seen, getting the host name takes many seconds each.


Henning

unread,
Apr 22, 2013, 7:37:32 AM4/22/13
to

"BeeJ" <nos...@spamnot.com> skrev i meddelandet
news:kkul4b$q0s$1...@dont-email.me...
Reread Jim Macks reply.

As for TCP/UDP ports:
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

Pick one that is unofficial.

If your'e interested in 192.168.3.0 network. Send an UDP packet saying
something you can decode at other computers as "Sender is Computer3 at
192.168.3.9" to 192.168.3.255:yourport#. That will be received by all
computers in the network that have an IP in range 192.168.3.1 to
192.168.3.254 listening to yourport#.

You can ofcause broadcast the "real" data the same way. Send to
192.168.3.255:yourport#, and all computers in your network listening to
yourport# will receive it.

/Henning



BeeJ

unread,
Apr 22, 2013, 11:34:57 AM4/22/13
to
> Reread Jim Macks reply.
>
> As for TCP/UDP ports:
> http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
>
> Pick one that is unofficial.
>
> If your'e interested in 192.168.3.0 network. Send an UDP packet saying
> something you can decode at other computers as "Sender is Computer3 at
> 192.168.3.9" to 192.168.3.255:yourport#. That will be received by all
> computers in the network that have an IP in range 192.168.3.1 to
> 192.168.3.254 listening to yourport#.
>
> You can ofcause broadcast the "real" data the same way. Send to
> 192.168.3.255:yourport#, and all computers in your network listening to
> yourport# will receive it.
>
> /Henning

Thank you! I will give that a try.


ralph

unread,
Apr 22, 2013, 1:31:24 PM4/22/13
to
On Mon, 22 Apr 2013 13:37:32 +0200, "Henning"
<comput...@coldmail.com> wrote:

>
>As for TCP/UDP ports:
>http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
>
>Pick one that is unofficial.
>
>If your'e interested in 192.168.3.0 network. Send an UDP packet saying
>something you can decode at other computers as "Sender is Computer3 at
>192.168.3.9" to 192.168.3.255:yourport#. That will be received by all
>computers in the network that have an IP in range 192.168.3.1 to
>192.168.3.254 listening to yourport#.
>
>You can ofcause broadcast the "real" data the same way. Send to
>192.168.3.255:yourport#, and all computers in your network listening to
>yourport# will receive it.
>

LOL
And thanks from me for that reminder.

Have a meeting later this week involving a similar situation - would
have been embarressing if I had presented my Rube Goldberg suggestion.
(And doubly embarressing to repeat it here.)

In this age of exotic services, one tends to forget the commonplace of
when all we had was TCP/UDP. <g>

-ralph

ObiWan

unread,
Apr 23, 2013, 12:08:28 PM4/23/13
to


> What I think I need is code that scans the 192.168.3.x range and
> reports who that is. Is there an API that I can use to do this?

Nope

http://en.wikipedia.org/wiki/Avalanche_%28P2P%29

http://research.microsoft.com/en-us/projects/avalanche/default.aspx

http://blogs.msdn.com/b/p2p/


ObiWan

unread,
Apr 23, 2013, 12:32:39 PM4/23/13
to

BeeJ

unread,
Apr 23, 2013, 9:10:58 PM4/23/13
to
ObiWan brought next idea :
Interesting.


ObiWan

unread,
Apr 24, 2013, 4:51:41 AM4/24/13
to

> > http://msdn.microsoft.com/en-us/library/dd407952%28VS.85%29.aspx

> Interesting.

basic idea is to use the above APIs to create your own "peer discovery"
so, instead of reinventing the wheel, your app will just use DRT to
announce it started and receive the list of other nodes and their IPs
then you can move on from that; as for sending files, I think you may
want to have a look at this API

http://msdn.microsoft.com/en-us/library/windows/desktop/ms740565%28v=vs.85%29.aspx

which will allow you to send files over a TCP connection at full speed;
you'll still need to implement the receiver part, but the above may be
a good start; another (although different) approach may be leveraging
the BITS APIs for your transfer needs

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363160%28v=vs.85%29.aspx

http://blogs.msdn.com/b/wmi/archive/2009/01/15/background-intelligent-transfer-service-bits.aspx

HTH

ObiWan

unread,
Apr 24, 2013, 5:12:31 AM4/24/13
to

> and their IPs then you can move on from that; as for sending files, I
> think you may want to have a look at this API
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms740565%28v=vs.85%29.aspx

darn me, forgot to add a note; if you look at the above API you'll
notice that the call takes a TRASMIT_FILE_BUFFERS structure as one of
its parameters, such a struct, which is defined here

http://msdn.microsoft.com/en-us/library/windows/desktop/ms740568%28v=vs.85%29.aspx

contains two buffer; namely head and tail; now, it's a good idea to use
those buffers to add to your file data stream some additional checks;
the idea is to create a structure like (e.g.)

Type tagFileHead
lngStructSize As Long ' LenB of this struct
strFileName As String * 255 ' filename.ext
lngFileSize As Long ' file size (bytes)
dtCreated As Date ' date created
dtModified As Date ' date last modified
lngAttrib As Long ' attributes
strChecksum As String * 50 ' checksum (e.g. MD5)
End Type

and fill the "header" buffer of TRASMIT_FILE_BUFFERS with it while
leaving the tail buffer empty; this way the TransmitFile API will
prepend the header to the file data when transmitting the file to the
remote end; the latter may then temporary save the whole data into a
temporary file, extract the header and use it not only to set back the
correct file name, attribute and dates, but also to check if the file
was correctly transmitted by recalculating the hash value on the file
data; the "lngStructSize" is there just to ease separating the header
from the data since you may just read such a size and know where to
"split" the header from the data


ralph

unread,
Apr 24, 2013, 10:11:58 AM4/24/13
to
On Wed, 24 Apr 2013 11:12:31 +0200, ObiWan
<alb.20.t...@spamgourmet.com> wrote:

Good summary. Good contribution.

Consider it all stolen. <g>

-ralph

ObiWan

unread,
Apr 24, 2013, 11:30:18 AM4/24/13
to

> Good summary. Good contribution.
>
> Consider it all stolen. <g>

:)

Just an additional note; the documentation

http://msdn.microsoft.com/en-us/library/ms740565%28VS.85%29.aspx

states that

"The hFile parameter is optional. If the hFile parameter is NULL, only
data in the header and/or the tail buffer is transmitted. Any
additional action, such as socket disconnect or reuse, is performed as
specified by the dwFlags parameter."

now, the above means that you may use the "TransmitFile()" API to
transmit a chunk of data you already have in memory (e.g. an image or
whatever); for such a purpose you'll just need to fill in the buffers
of the "TRANSMIT_FILE_BUFFERS" structure and pass a null file handle;
this way only the buffers will be transmitted to the remote end; this
"trick" may come handy in a number of cases; for example you may
serialize an array, add the array info in the header block and the
serialized array in the tail block and send just the buffer in a single
operation :)







0 new messages