DESCRIPTION
BACKGROUND
Field of the Invention
[0001] The invention relates to a method, system and computer program product for tile
sharing between electronic devices connected to a network. The invention is capable of being
implemented on electronic devices with network connectivity, including handheld devices.
While the present disclosure discusses the invention in terms of wireless networks, the invention
is equally applicable to wired networks.
Description of Prior Art
[0002] Electronic devices capable of network communication include personal computers,
laptops, tablets, personal digital assistants (PDAs) and mobile telecommunication devices
(mobile phones). Such devices are now routinely provided with network access capabilities,
including wireless network access capabilities, which enable such devices to communicate with
other devices connected through such networks, or to access the internet through such network.
[0003] Despite the network capabilities, the alternatives available to devices seeking to share
tiles over a network remain limited, in that users typically require (i) to use local storage
mediums (such as CDs, DVDs or flash memory),(ii) connect the devices directly using a
connecting bus (such as a network cable), (iii) use Near Field Communication (NFC) or
Bluetooth technology now provided for on many electronic handheld devices such as mobile
phones (iv) utilize an online file storage service or (v) utilize an internet based peer to peer (P2P)
file sharing service, which requires a user to access the internet and search for files shared by
other users using the P2P service.
[0004] Drawbacks to prior art solutions involving a local storage medium or a connecting
bus is that both electronic devices require to be capable of accessing such local storage medium
or connecting bus - which is increasingly not the case, with tablets, PDAs and mobile phones. In
•
the case of NFC communication, both electronic devices need to be maintained in close
proximity (typically a few centimetres) for the duration of the file transfer. For Bluetooth based
transfers, both devices require to be Bluetooth enabled, located within a predefined distance of
each other, and paired with each other to enable a transfer. Similarly, in the case of online
storage accounts and internet based P2P services, the file transfer is immediately subject to
internet bandwidth limitations and security concerns associated with internet communications.
Additionally, depending on the internet service provider's terms of service, there may also be a
recurring cost arising from internet usage to transfer files.
[0005] There is therefore a need for a file sharing solution that allows electronic devices
connected to a wireless network to share files directly with each other.
SUMMARY OF THE INVENTION
[0006] The invention comprises a method, electronic device and computer program product
for sharing files between a plurality of electronic peer devices connected to a wireless network.
[0007] The method of the invention comprises the steps of sending from a first peer device,
a request for transfer of at least one shareable file or folder from a remote peer device, and
receiving at the first peer device, the requested at least one shareable file or folder from the
remote peer device.
[0008] In an embodiment of the method sending the request for transfer may be preceded by
sending from the first peer device, a request for listing shareable files or folders stored on the
remote peer device. Alternatively, the request for transfer may be preceded by receiving from the
remote peer device, a request to allow transmissi.on of at least one shareable file or folder stored
on the remote peer device, from the remote peer device to the first peer device.
[0009] In a further embodiment of the method, sending of the request for listing shareable
files or folders stored on the remote peer device may be followed by receiving at the first peer
device, a response listing shareable files or folders stored on the remote peer device.
•
[00010] Requests and responses between the first peer device and the remote peer device may
be communicated over the wireless network.
[00011] In an embodiment, the first peer device may send the request for listing shareable
files or folders to a network address of a remote peer device, obtained by the first peer device
during device discovery.
[00012] In the inventive method, device discovery may comprise sending from the first
peer device to a broadcast address of the wireless network, a handshake request comprising a
unique network address corresponding to the first peer device. Device discovery may
additionally comprise receiving from at least one remote peer device, a handshake response
comprising a unique network address corresponding to such remote peer device.
[00013] The peer device connected to the wireless network may store information received
through handshake requests and handshake responses in a local memory, which information
enables such peer device to identify and communicate with other peer devices.
[00014] In a specific embodiment of the method at least one request sent from the first peer
device to the remote peer device includes a maximum chunk size which the first peer device is
capable of receiving from the remote peer device, and wherein chunk size represents the size of a
discrete data unit transmitted between peer devices.
[00015] In implementing the file sharing method, the first peer device may receive from the
remote peer device a data file that has been broken into chunks having a size less than or equal to
the smaller of (i) the maximum chunk size which the first peer device is capable of receiving
from the remote peer device and (ii) a maximum chunk size which the remote peer device is
capable of transmitting to the first peer device.
•
[00016] In an embodiment, the maximum chunk size corresponding to at least one of the first
peer device and the remote peer device is determined based on primary memory available to the
corresponding device.
[00017] In implementing the method, the first peer device may execute multiple simultaneous
file transfers with remote peer devices. Executing multiple simultaneous file transfers between
the first peer device and remote peer devices may include one or more of (i) adding a request for
transfer of at least one shareable file or folder located at a remote peer device to a queue within
the first peer device, (ii) sending the request for transfer to the remote peer device when the first
peer device has a vacant active transfer slot capable of accommodating the request for transfer,
(iii) adding the request for transfer to a queue within the remote peer device, (iv) deleting the
request for transfer from the queue within the first peer device, provided the remote peer device
does not have a vacant active transfer slot capable of accommodating the request for transfer,
and (v) transferring the file or folder requested by the first peer device through the request for
transfer, when both the first peer device and remote peer device simultaneously have a vacant
active transfer slot capable of accommodating the request for transfer.
[00018] In an embodiment of the method, deletion of the request for transfer from the queue
within the first peer device may be followed by one or more of (i) sending the request for transfer
to the first peer device when the remote peer device has a vacant active transfer slot capable of
accommodating the request for transfer, (ii) adding the request for transfer to the queue within
the first peer device, and (iii) deleting the request for transfer from the queue within the remote
peer device, provided the first peer device does not have a vacant active transfer slot capable of
accommodating the request for transfer.
[00019] In a further embodiment, deletion of the request for transfer from the queue within
the remote peer device may be followed by one or more of (i) sending the request for transfer to
the remote peer device when the first peer device has a vacant active transfer slot capable of
accommodating the request for transfer, (ii) adding the request for transfer to the queue within
the remote peer device, and (iii) deleting the request for transfer from the queue within the first
•
peer device, provided the remote peer device does not have a vacant active transfer slot capable
of accommodating the request for transfer.
[00020] It would be understood that the computer program product implementation of the
invention may include a non-transitory computer usable medium having a computer readable
program code, which code includes instructions for carrying out one or more of the method steps
of the method implementation.
[00021] In a device embodiment for sharing files with a plurality of peer electronic devices
connected to a wireless network, an electronic device comprises a wireless transceiver, a primary
memory, a secondary memory and a processor. The processor of the electronic device may be
configured to send from the electronic device, a request for transfer of at least one shareable file
or folder stored on a remote peer device, and receive at the electronic device, the
requested at least one shareable file or folder from the remote peer device.
[00022] The processor may further be configured to precede sending the request for transfer
by sending from the electronic device, a request for listing shareable files or folders stored on the
remote peer device. Alternatively, the processor may further be configured to precede sending
the request for transfer, by receiving at the electronic device, a request to allow transmission of at
least one shareable file or folder from the remote peer device.
[00023] The processor may also be configured to receive a response listing shareable files or
folders stored on the remote peer device, subsequent to the sending of the request for listing
shareable files or folders stored on the remote peer device.
[00024] In an embodiment, the processor is configured to communicate requests and
responses to remote peer devices over the wireless network.
[00025] The processor may be configured to send the request for listing shareable files or
folders to a network address of a remote peer device obtained by the electronic device during
device discovery. In a specific embodiment, device discovery is enabled by configuring the
•
processor to (i) send to a broadcast address of the wireless network, a handshake request
comprising a unique network address corresponding to the electronic device, and (ii) receive
from at least one remote peer device, a handshake response comprising a unique network address
corresponding to such at least one remote peer device.
[00026] The processor of the electronic device may be configured to store information
received through handshake requests and handshake responses in a local memory, which
information enables the electronic device to identify and communicate with remote peer devices.
[00027] In a particular embodiment, the processor of electronic device may be configured to
include in at least one request sent to the remote peer device, a maximum chunk size which the
electronic device is capable of receiving from the remote peer device, wherein chunk size
represents the size of a discrete data unit transmitted between peer devices.
[00028] The processor may additionally be configured to receive from the remote peer device
a data file that has been broken into chunks having a size less than or equal to the smaller of (i)
the maximum chunk size which the electronic device is capable of receiving from the remote
peer device and (ii) a maximum chunk size which the remote peer device is capable of
transmitting to the electronic device.
[00029] In an embodiment of the electronic device, the processor may be configured to
determine maximum chunk size based on primary memory available to the electronic device.
[00030] The processor of the electronic device may be configured to execute multiple
simultaneous file transfers with remote peer devices. In an embodiment, the processor may be
configured to (i) add a request for transfer of at least one shareable file or folder located at a
remote peer device to a queue within the electronic device, (ii) send the request for transfer to the
remote peer device when the electronic device has a vacant active transfer slot capable of
accommodating the request for transfer, (iii) delete the request for transfer from the queue within
the electronic device, provided the remote peer device does not have a vacant active transfer slot
capable of accommodating the request for transfer, and (iv) receive transfer of the file or folder
7
•
requested by the electronic device when both the electronic device and remote peer device each
simultaneously have a vacant active transfer slot capable of accommodating the request for
transfer.
[00031] The processor may additionally be configured to respond to deletion of the request
for transfer from the queue within the electronic device by (i) receiving the request for transfer
from the remote peer device, when the remote peer device has a vacant active transfer slot
capable of accommodating the request for transfer, and (ii) adding the request for transfer to the
queue within the electronic device, provided the first peer device does not have a vacant active
transfer slot capable of accommodating the request for transfer.
[00032] Further, the processor may be configured to respond to deletion of the request for
transfer from the queue within the remote peer device by (i) sending the request for transfer to
the remote peer device when the electronic device has a vacant active transfer slot capable of
accommodating the request for transfer, and (ii) deleting the request for transfer from the queue
within the electronic device, provided the remote peer device does not have a vacant active
transfer slot capable of accommodating the request for transfer.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
[00033]
[00034]
[00035]
[00036]
[00037]
[00038]
Figure 1 illustrates an exemplary electronic device of the invention.
Figure 2 illustrates an exemplary wireless network.
Figure 3 describes device discovery implemented by the invention.
Figure 4A illustrates a message format for a handshake request message.
Figure 4B illustrates a message format for a handshake response message.
Figure 4B illustrates a message format for a handshake response message.
•
[00039] Figure 5 illustrates a method of communicating a list of public files available on
one peer device to another peer device.
[00040]
[00041]
Figure 6A illustrates a message format for a public file list request.
Figure 6B illustrates a message format for a public file list response.
[00042] Figure 7A describes a method of transferring files from one electronic device to
another over a sharing network in a pull implementation.
[00043]
device.
Figure 7B illustrates a message format for a data request sent by a requesting peer
[00044] Figure 7C illustrates a message format for a data response message sent by a
target peer device.
[00045] Figure 8A describes a method of transferring files from one electronic device to
another over a file sharing network in a push implementation.
[00046]
[00047]
[00048]
Figure 8B illustrates a message format for a request transmit message.
Figure 8C illustrates a message format for a response transmit message.
Figure 8D illustrates a message format for a data transfer request message.
DETAILED DESCRIPTION OF THE INVENTION
[00049] The invention presents a method, system and computer program product for enabling
sharing of files between electronic devices connected to a wireless network. The invention
enables electronic devices connected to the wireless network to identify other electronic devices
9
•
with file sharing capabilities. The invention additionally enables a user of an electronic device to
identify files that are intended for sharing (public files) with other users on the wireless network.
An electronic device with file sharing capabilities is capable of viewing public files stored on
other electronic devices connected to the network, and may request one or more of such public
files. An electronic device receiving a request for a public file may respond to such request by
transferring the requested file to the requesting electronic device.
[ 00050] For the purposes of this invention the term "electronic device(s)" shall be understood
to include one or more of personal computers, laptops, servers, tablets, gaming consoles, and
handheld devices including personal digital assistants (PDAs) and mobile telecommunication
devices (mobile phones). Figure 1 illustrates an exemplary electronic device 100, having
processor 102, primary memory 104, secondary memory 106, and wireless transceiver 108.
[00051] Figure 2 illustrates an exemplary wireless network 200 having wireless access point
202, and multiple electronic devices 204, 206, 208 and 210 connected to the wireless network
200 through wireless access point 202. In the illustrated embodiment, wireless access point 202
is a wi-fi router, electronic device 204 is a desktop personal computer, electronic device 206 is a
laptop, electronic device 208 is a mobile phone having wireless network capabilities and
electronic device 210 is a tablet. Wireless access point 202 may in other embodiments include
wireless methodologies implemented with an electrical, optical, RF, infrared, acoustic,
microwave, Bluetooth or other transmission media. In a particular embodiment wireless access
point 202 is a mobile wireless hotspot i.e. a wireless access point created by a handheld
electronic device (such as a mobile phone or other mobile electronic device) having at least a
wireless transceiver and an internet connection. When operating as a mobile wireless hotspot, the
handheld electronic d~vice behaves like a wireless router, creating a network and enabling other
wireless devices to connect to the network and share the handheld electronic device's internet
connection.
[00052] The wireless network based file transfer contemplated by the invention comprises the
steps of (i) device discovery (ii) listing public files (iii) file transfer and (iv) queue management.
Each of the above are described in further detail.
ID
•
Device Discovery
[00053] Figure 3 describes device discovery implemented by the invention.
[00054] At step 302, a first electronic device configured to implement the invention and
having a unique identifier, connects to the wireless network through a wireless access point. The
unique identifier (which in an embodiment may be a unique network address) is capable of
distinguishing the electronic device from other hosts connected to the wireless network. In an
embodiment, the unique identifier is the IP address or MAC address allocated to the electronic
device.
[00055] At step 304, the first electronic device obtains the broadcast address for the wireless
network. The broadcast address is a logical network address at which all devices connected to the
network (network hosts) are capable of receiving messages - i.e. a message sent to a broadcast
address is received by all network hosts instead of by only a specific device.
[00056] Thereafter at step 306, the first electronic device (the broadcasting device) sends a
handshake request message to the broadcast address - which handshake request message is
received by all hosts on the wireless network. While contents of the handshake request message
are described in further detail in connection with Figure 4A below, information communicated
in the handshake request message may include a network address of the broadcasting device and
information regarding the broadcasting device capabilities.
[00057] At step 308, if a second electronic device receiving the handshake request message is
not configured to implement the file sharing method, the second electronic device does not
respond to the handshake request message.
[00058] If the second electronic device (responding device) is configured to implement the
file sharing method, it responds at step 310 by storing the information received from the
\ •
broadcasting device in a memory for subsequent access and sending a handshake response
message to the broadcasting device at the broadcasting device's network address.
[00059] All handshake request information received by a responding device is stored in a
memory for subsequent use. In an embodiment, if the responding device already has an entry for
the broadcasting device, the earlier entry is overwritten by the new information. The responding
device may additionally create a log entry in memory, recording the data and time when each
entry was received. The corresponding data and time stamp may be overwritten each time an
older record is overwritten with new information.
[00060] The handshake response message is communicated from the responding device to the
broadcasting device by a unicast message. While contents of the handshake response message
are described in further detail in connection with Figure 4B below, information communicated
in the handshake response message may include a network address of the responding device and
information regarding the responding device capabilities.
[00061] At step 312, the broadcasting device receives the handshake response message and
stores the information received in the handshake response message in a memory for subsequent
access.
[00062] rt would be understood that at the end of step 312, each responding device would
have received and recorded network information regarding the broadcasting device and also the
fact that the broadcasting device is capable of implementing the file sharing method. Likewise,
the broadcasting device would have received and stored network information regarding each
responding device and the fact that such responding device is capable of implementing the file
sharing method. The information enables the broadcasting device and each responding device to
recognize each other as peer devices within a file sharing network implemented over the wireless
network. This information further enables each peer device to identify and communicate with
other peer devices within the file sharing network. At the end of this process, the network has
completed the process of device discovery insofar as the broadcasting device is concerned, and
•
the broadcasting device and each responding device are thereafter peer devices connected to
form a file sharing network implemented on the wireless network.
[00063] In an embodiment of the invention, the handshake request message sent by the
broadcasting device may correspond to the message format illustrated in Figure 4A, wherein:
• req_finder~the message name - designates the intended use of the message to a
remote device.
• ip~ the IP address of the broadcasting device. In an embodiment the IP address may
be replaced by the MAC address. The IP address is used to identify the device on
the network.
• name~name of the device as set by the user.
• uuid~ UnIque identifier used to identify the device on the network. In an
embodiment, the UUID is a 28 byte long alpha numeric string.
• iconno~ an integer used when displaying an icon for a device. The icon and name
of the device will be visible to remote devices when the handshake is complete.
• Icon~contains an entire resized image if the user selects a custom icon image. In an
embodiment, the icon is transferred in byte form.
• platform name~identifiesthe device type i.e. whether the device is a tablet, mobile
phone, personal computer, laptop etc.
• pIatform~ identifies the device operating system and operating system version.
• version~identifies version of an application implementing the file sharing method
and running on the device.
•
• chunksize~ the maximum size of a chunk that the device may receive.
[00064] For the purposes of the invention, a chunk denotes a block of data treated as a
discrete data unit for file transfer i.e. a transmitting device would split a file intended for
transmission into multiple chunks and transmit such chunks as discrete units to a receiving
device. The chunks would be received at the receiving device and reassembled into the complete
tile.
[00065] In an embodiment of the invention, the handshake response message sent by a
responding device may correspond to the message format in Figure 4B wherein:
• res_finder~ the message name - designates the intended use of the message to a
remote device.
• ip~ the IP address of the responding device information. In an embodiment the IP
address may be replaced by the MAC address. The IP address is used to identify the
device on the network.
• name~name of the device as set by the user.
• uuid~ UnIque identifier used to identify the device on the network. In an
embodiment, the UUID is a 28 byte long alpha numeric string.
• iconno~ an integer to be used when displaying an icon for a device. The icon and
name of the device will be visible to remote devices when the handshake is
complete.
• icon~ contains an entire resized image if the user selects a custom image
1'1
•
• platformname.-7identifies the device type i.e. whether the device is a tablet, mobile
phone, personal computer, laptop etc.
• platform.-7identifies the device operating system and operating system version.
• version.-7identifies version of an application implementing the file sharing method
and running on the device.
• chunksize.-7the maximum size of a chunk that the device may receive.
Listing Public Files
[00066] Upon completion of the device discovery process, a user ofa first peer device within
the file sharing network will be able to view all other peer devices in the file sharing network.
Users of the remaining peer devices (remote peer devices) may correspondingly view the first
peer device. Additionally, each peer device within the file sharing network now has a network
identifier such as the IP address or MAC address of each of the remaining peer devices within
the network, which network identifier may be used to forward subsequent requests or responses
from a first peer device to any remote peer device within the file sharing network.
[00067] A user at any peer device may thereafter identify specific files or folders as public
files i.e. files and folders that are intended for sharing with remote peer devices.
[00068] All files and folders stored within the memory of a peer device of the file sharing
network are by default marked as private. Private files and folders may only be viewed and
accessed by the user of the peer device itself. For a user to make a file or a folder viewable and
shareable by peer devices, such file or folder requires to be identified as a public file. A user of a
peer device may mark a file or folder stored in the memory of the peer device as public.
[00069] A file or folder (item) can be marked with an access specifier (private or public).
This may be achieved in a number of ways:
15
•
1) All items may be stored in the memory along with their corresponding access specifiers.
In this implementation, the structure of the items is maintained and no additional copies of
the items are created. If the access specifier for any item changes it is updated into the
memory.
2) Items belonging to only one access specifier may be stored in memory. It would be
understood that this implementation does not work well if there are more than two access
specifiers.
3) Items may be moved to different parts of the memory based on their access specifiers. In
this implementation copies are made of the original item which copies are then stored in
logical locations determined by access specifiers. This implementation involves an
overhead of creating multiple copies of items which is memory inefficient.
4) An index may be maintained mirroring the structure of the items and the index is then
populated with the correct access specifiers for each item within the index. This method
involves a memory overhead arising from the necessity of maintaining the index.
[00070] When a file or folder has been marked public, the peer device on which such file or
folder is stored thereafter moves the file or adds a copy of such file to a specifically designated
portion of memory allocated for public files and folders. The memory allocated for public files or
folders may consist of a physical or logical partition i.e. may comprise an actual physical
segment of the memory, or a logical set of folders allocated for storing public files and folders.
In an embodiment, if the user marks a folder as public, all files and sub-folders within the folder
are correspondingly marked public.
[00071] Figure 5 illustrates a method of communicating a list of public files available on one
peer device to another peer device.
16
•
[00072] To view files available for sharing on another peer device within the file sharing
network, a first peer device (the requesting peer device) forwards at step 502, a public file list
request to such other peer device (the target peer device), at the target peer device's network
address. While contents of the public file list request are described in further detail in connection
with Figure 6A below, information communicated in the request would include at least a
network address of the requesting peer device.
[00073] In an embodiment, the first time a public file list request is made by a requesting peer
device to a target peer device, the request may call for a file listing of the root folder containing
public files. In subsequent requests, the request may identify specific files or folders within the
root folder, which files or folders are identified based on the public file list received from the
target peer device.
[00074] Upon receipt of a public file list request, at step 504, the target peer device sends to
the requesting peer device a public file list response, including the file listing for the folder
identified in the request received from the requesting peer device. Contents of the public file list
response are described in further detail in connection with Figure 6B below.
[00075] At step 506, the requesting peer device receives and stores in memory the list of
public. files received from the target peer device, which list of public files may be viewed by a
user at the requesting peer device.
[00076] In an embodiment of the invention, the public file list request sent by the requesting
peer device may correspond to the message format illustrated in Figure 6A, wherein:
• req_lof~ the message name - designates the intended use of the message to a
remote device.
• ip~the network identifier used to identify the requesting peer device.
17
•
• revision_no~ is the current revision number of the target peer device as stored with
the requesting peer device. In an embodiment of the invention revision numbers are
maintained on all peer devices within the file sharing network. Whenever a file or
folder is added or deleted from the body of public files and folders, the revision
number for that device is incremented. By receiving the current revision number of
the target peer device as stored with the requesting peer device, the target peer
device can determine whether the requesting peer device already has the most up to
date public file listing of the target peer device.
• fileid~identifies the folder for which data has been requested. In an embodiment,
when a requesting peer device makes a public file list request for the first time from
a target peer device, the file id is 0 - denoting a request for a listing of the root
folder of public files. In subsequent requests the file id may correspond to an actual
file or folder for which the requesting peer device requires a listing.
[00077] In an embodiment of the invention, the public file list response sent by the target peer
device may correspond to the message format illustrated in Figure 68, wherein:
• res_Iof~the message name - designates the intended use of the message to a remote
device.
• ip~provides the network identifier of the target peer device.
• uuid~provides the unique identifier of the target peer device.
• revisionno~provides the revision number of the public files on the target peer device. In
an embodiment of the invention revision numbers are maintained on all peer devices
within the file sharing network. Whenever a file or folder is added or deleted from the
body of public files and folders, the revision number for that device is incremented.
• fileid~provides the file id of the folder for which the response has been generated.
•
• filename~provides details of the files present under the folder such as name, size, folder
id of the folder it is present in, and base folder id.
• folder~ provides folder name details if one of the entries in the listing is a folder. The
name details include one or more of name, id and parent folder id.
[00078] It would be understood that the above requests and responses for public file listings
maybe used to share public file listings between any two peer devices within the file sharing
network.
File Transfer
[00079] The invention contemplates transfer of files through a "pull implementation" or
through a "push implementation".
File Transfer In Pull Implementation
[00080] Figure 7A describes the method of transferring files from one electronic device to
another over the file sharing network in a pull implementation.
[00081] At step 702, a user accessing a peer device (requesting peer device) identifies a file
that is available for sharing on a remote peer device (target peer device) within the file sharing
network. Files available on remote peer devices may be identified based on a listing of public
files received from such remote peer devices, in accordance with the methods discussed above.
[00082] At step 704, the requesting peer device sends a data transfer request to the target peer
device, identifying the file for transfer. While contents of the data request are described in further
detail in connection with Figure 7B below, information communicated in the request may
include a network identifier of the requesting peer device, an identifier corresponding to the
•
requested data file, and a maximum chunk size that the requesting peer device is capable of
handling in the course of the data transfer.
[00083] At step 706, the target peer device receives the data transfer request. At 708 the
target peer device identifies the requested file based on the file identifier received with the data
transfer request. At step 710 the target peer device breaks the' requested file into one or more
chunks, wherein the size of each chunk is less than or equal to the maximum chunk size specified
in the data transfer request.
[00084] In the event the size of the requested file is less than the specified chunk size, the
entire file may be transferred as a single chunk. If the file size is greater than the specified chunk
size, the file would require be broken up into multiple chunks prior to transmission, wherein the
size of each chunk is less than or equal to the specified chunk size.
[00085] Each chunk is wrapped into a discrete data response message and sent back to the
requesting peer device at step 712. The contents of data response messages are discussed in
further detail in connection with Figure 7C below. At step 714 the response messages are
received at the requesting peer device, wherefrom the data chunks are extracted, reassembled
into the requested file and written to memory of the requesting peer device.
[00086] In an embodiment of the invention, each peer device is capable of determining a
maximum chunk size for file transfers that the device is involved in. In a preferred embodiment,
each peer device determines a maximum chunk size based on at least one of available primary
memory and number of simultaneous transfers or active threads under execution at the device. In
view that the invention seeks to facilitate wireless file sharing between multiple electronic
devices including handheld devices such as mobile phones (which have significant primary
memory restrictions in comparison to other devices such as personal computers, laptops, tablets
etc.) specifying maximum chunk sizes allows the invention to be configured for computational
efficiencies depending on the hardware configuration of each individual device and platform.
•
[00087] In an embodiment of the invention, the target peer device may lack the capability (in
terms of available primary memory or for other reasons) to handle the maximum chunk size
specified by the requesting peer device. In such cases, the target peer device may select a chunk
size lesser than the chunk size specified by the requesting peer device, and may break the file
into chunks of the lesser chunk size. In an embodiment The lesser chunk size may be selected as
the minimum of the chunk sizes of the two devices.
[00088] In a pull implementation of the invention, the data request sent by the requesting peer
device may correspond to the message fonnat illustrated in Figure 7B, wherein:
• req_transfer-7 the message name - designates the intended use of the message. to a
remote device.
• ip-7 is the network identifier of the requesting peer device.
• uuid-7 is the unique identifier of the requesting peer device.
• cons_tCid-7 is a unique identifier generated for the user, and identifies the particular
transfer on the requesting device. This identifier is required as there may be multiple
transfers ongoing between any two devices on the network.
• fiIe_id-7 is the identifier for the file that is requested for transfer.
• revision_DO-7 is the revision number of the file set being hosted by the target peer
device
• name-7provides the name of the file being transferred.
• chunk_size-7 provides the maximum size of a chunk that the requesting peer device
may receive.
2•
[00089] In a pull implementation of the invention, data response messages sent by the target
peer device may correspond to the message format illustrated in Figure 7C, wherein:
• res_transfer~ the message name - designates the intended use of the message to a
remote device.
• ip~provides the network identifier of the target peer device.
• uuid~ provides the unique identifier of the target peer device.
• type~identifies the payload type in the data response message. Different identifiers
may be used for different file types e.g. for root level files, folders, ordinary files, or
files within a folder.
• cons_tf_id~ provides an id used to identify the particular transfer on the requesting
device.
• prod_tCid~provides a transfer id for the user of the target peer device, which is
used to identify the particular transfer on the target peer device.
• file data type~identifies whether a standalone file is being transferred or a file
within a folder is being transferred.
• name~ provides the name of the file being transferred.
• chunk no~provides the chunk number of the file being transferred.
• total chunks~provides the maximum number of chunks for the file under transfer.
• md5~provides the checksum of the particular file chunk under transfer.
22-
•
• bytes~used to store the actual payload i.e. the data in byte form that is used to create
the payload.
[00090] The above data requests and data response messages may be used to transfer files
between any two peer devices within the file sharing network in a pull implementation of the
invention.
File Transfer In Push Implementation
[00091] Figure 8A describes the method of transferring files from one electronic device to
another over the file sharing network in a push implementation.
[00092] At step 802, a peer device hosting one or more files (transmitting peer device)
identifies at least one file hosted thereon, which is intended for transfer to a remote peer device
(target peer device). In an embodiment, the at least one file identified as intended for transfer is
identified by a user at the transmitting peer device.
[00093] At step 804, the transmitting peer device sends a request to allow transmission of at
least one shareable file or folder stored on the remote peer device (request transmit message) to
the target peer device. While contents of the request transmit message are described in further
detail in connection with Figure 8B below, information communicated in the request transmit
message may include a network identifier of the transmitting peer device, an identifier
corresponding to the data file intended for transfer, a transfer identifier generated by the
transmitting peer device, and a maximum chunk size that the transmitting peer device is capable
of handling in the course of the data transfer.
[00094] At step 806, the target peer device receives the request transmit message. At step 808
the target peer device takes a decision whether to accept the transmit request. In an embodiment,
the decision whether to accept the transmit request is taken by a user at the target peer device.
•
[00095] If the target peer device decides not to accept the transmit user request, the
transmitting peer device is notified of the refusal at step 810a and the file transfer is thereafter
terminated. Notification of the refusal is achieved by the target peer device sending a response
transmit message to the transmitting peer device. While contents of the response transmit
message are described in further detail in connection with Figure 8C below, information
communicated in the response transmit message may include a network identifier of the target
peer device, information regarding the response itself, and the corresponding transfer identifier
originally generated by the transmitting peer device.
[00096] If the target peer device accepts the transmit user request, the transmitting peer
device is notified of the acceptance at step 810b. Notification of the acceptance is achieved by
the target peer device sending a response transmit message to the transmitting peer device. While
contents of the response transmit message are described in further detail in Figure 8C below,
information communicated in the response transmit message may include a network identifier of
the target peer device, information regarding the response itself, and the corresponding transfer
identifier originally generated by the transmitting peer device.
[00097] Thereafter, at step 812, the target peer device generates a data transfer request
message (for sending to the transmitting peer device) seeking transfer of the file(s) identified in
the request transmit message, from the transmitting peer device to the target peer device. At step
814, the file transfer is thereafter achieved according to the method steps previously described in
connection with steps 704 to 714 of Figure 7A in connection with the pull implementation of the
fi Ie transfer method.
[00098] While contents of the data transfer request message are described in further detail in
connection with Figure 8D below, information communicated in the data transfer request
message may include a network identifier of the target peer device, information regarding the
response itself, a transfer identifier generated by the target peer device, and the transfer identifier
originally generated by the transmitting peer device.
•
[00099] In a push implementation of the invention, request transmit messages sent by the
transmitting peer device may correspond to the message format illustrated in Figure 8B, wherein:
• ip 7 is the network identifier used to identify the device where the command
originates.
• name 7 is the name of the transmitting peer device.
• uuid 7 is the unique identifier of the transmitting peer device.
• prod_name 7 is name of the device hosting the file intended for transfer.
• prod_size 7 specifies the maximum size of a chunk that the transmitting peer device
may handle.
• prod_tCido7 is a transfer identifier generated at the transmitting peer device.
• Cid 7 is a file identifier.
• Cname 7 is the name of the folder, if a folder is being transferred.
• is_f 7 is a variable to specify whether a file or folder is being transferred.
• Csize 7 specifies the size of the file being transferred.
[000100] In a push implementation of the invention, response transmit messages sent by the
target peer notifying the transmitting peer device of either refusal or acceptance of the request
transmittal message, may correspond to the message format illustrated in Figure 8e, wherein:
• ipo7 is the network identifier used to identify the target peer device.
• uuid 7 is the unique identifier of the target peer device.
• type 7 is used to specify the type of response being sent.
• prod_tCid 7 is the transfer identifier generated at the transmitting peer device.
[000101] In a push implementation of the invention, data transfer request messages sent by
the target peer device to the transmitting peer device may correspond to the message format
illustrated in Figure 8D, wherein:
• ip 7 is the network identifier used to identify the target peer device.
25
•
• uuid -7 is the unique identifier of the target peer device.
• type -7 specifies the type of response.
• cons_tCid -7 is the transfer identifier generated on target peer device.
• prod_tCid -7 is the transfer identifier generated at the transmitting peer device.
[000102] The above data req uests and data response messages may be used to transfer fi les
between any two peer devices within the file sharing network in a push implementation of the
invention.
Queue Management
[000103] In addition to the above, the invention also provides a method for managing
multiple simultaneous transfers involving peer devices on the wireless network.
[000104] To enable multiple simultaneous transfers, each peer device maintains a transfer
queue capable of accommodating a finite set of transfers involving the device. In an
embodiment, a peer device transfer queue may accommodate upto 1024 simultaneous transfers.
In addition, each device has a maximum number of active transfers that it can handle
simultaneously at any point of time. It would be understood that the maximum number of active
transfers per peer device is necessarily less than or equal to the queue size.
[000105] Figure 9 describes the process of queue management for a peer device sending out
a request (for example, a handshake request, a public file list request or a data request). At step
902, the requesting peer device checks whether there is a vacant slot in queue. If no vacant slot is
available in the queue, the requesting peer device may at step 902asimply notify the user to try
again later. If a vacant slot is available, the request is added to the end of the queue at step 904.
At step 906 the requesting peer device checks to ascertain whether the specified limit for active
transfers has been reached. If the specified limit for active transfers has been reached, the
requesting peer device waits for at least one active transfer to be completed and so that the peer
device has a vacant active transfer slot. Thereafter, at step 908, the requesting peer device checks
to ascertain whether the request is at the head of the queue. If not, the requesting peer device, at
26
•
step 908a, moves the task at the head of the queue to the vacant active transfer slot. This
continues until at step 910the request reaches the top of the queue and an active transfer slot
becomes available, whereafter at step 912, the request is sent by the requesting peer device. In an
embodiment, each device on the network maintains its own queue.
[000106] Figure 10 describes the process of queue management for a peer device receiving
a file transfer request. At step 1002, the request is added to the receiving device's queue. At step
1004, the receiving device ascertains whether it has a vacant active transfer slot capable of
accommodating the transfer request. If yes, the receiving device commences transfer of the file
to the requesting device at step 1004a. If no, at step 1006, the requesting device is notified
regarding unavailability of an active transfer slot at the receiving device, whereupon the transfer
request is deleted from the requesting device's queue, and the requesting device continues with
execution of the remaining tasks in its queue.
[000107] At step 1008, the receiving device continues to execute tasks in its queue until it
identifies a vacant active transfer slot capable of accommodating the transfer request. Thereupon,
at step 1010, the transfer request is once again added to the requesting device's queue. The
requesting device then ascertains at step 1012, whether it has a vacant active transfer slot capable
of accommodating the transfer request.
[000108] If yes, the receiving device and requesting device commence transfer of the file at
step 1004a. If no, at step 1014, the receiving device is notified regarding unavailability of an
active transfer slot at the requesting device, whereupon the transfer request is deleted from the
receiving device's queue, and the receiving device continues with execution of the remaining
tasks in its queue.
[000109] At step 1016, the requesting device once again continues to execute tasks in its
queue until it identifies a vacant active transfer slot capable of accommodating the transfer
request - whereupon the entire method of Figure 10 repeats itself, until a transfer is eventually
commenced at step 1004a.
21
•
[000110] The queue management method described above presents significant advantages
in terms of computational efficiencies - in that it ensures that a transfer request is not
simultaneously maintained in the active transfer slot of two peer devices while waiting for an
active transfer slot in one of such two devices to fall vacant. This optimizes the number of
simultaneous active transfers any peer device can execute at a given point in time. Additionally,
by ensuring that only a single copy of a transfer request is maintained on the file sharing network
at any point of time, the queue management method also offers significant memory related
efficiencies, which are important in the case of handheld electronic devices such as mobile
phones - which often have significant limitations on the amount of available primary memory.
[000111] It would be understood that the implementing environment of the invention is not
intended to be limited to the specific device and method embodiments discussed above. By way
of example in Figure 1, the processor 102 executes program instructions and may be a real
processor. The processor 102may also be a virtual processor. The processor 102 may equally
comprise a programmed microprocessor, a micro-controller, a peripheral integrated circuit
element, and other devices or arrangements of devices that are capable of implementing the steps
that constitute the method of the present invention. In an embodiment of the present invention,
one or both of the primary memory 104 and secondary memoryl06 may store software for
implementing various embodiments of the present invention. Examples of primary memory 104
may include but are not limited to random access memory (RAM), dynamic RAM (DRAM) and
cache memory. Examples of secondary memory 106 may include but are not limited to magnetic
disks, magnetic tapes, CD-ROMs, CD-RWs, DVDs, flash drives or any other medium which can
be used to store information and can be accessed by the electronic device 100. In various
embodiments of the present invention, the storage contains program instructions for
implementing the described embodiments.
[000112] The electronic device 100 may have additional components. For example, the
electronic device 100 may include one or more communication channels, one or more input
devices, one or more output devices, and additional storage devices. An interconnection
mechanism (not shown) such as a bus, controller, or networks, may interconnect the components
•
of the electronic device 100. In various embodiments of the present invention, operating system
software (not shown) provides an operating environment for various softwares executing in the
electronic device 100, and manages different functionalities of the components of the electronic
device 100.
[ 000113] The input electronic device 100 may further include input devices such as, but not
limited to, a keyboard, mouse, pen, joystick, trackball, a voice device, a scanning device, or any
another device that is capable of providing input to the electronic device 100. In an embodiment
of the present invention, the input device(s) may be a sound card or similar device that accepts
audio input in analog or digital form. The output device(s) may include, but is not limited to, a
user interface on CRT or LCD, printer, speaker, CD/DVD writer, or any other device that
provides output from the electronic device 100.
[000114] The present invention may be implemented in numerous ways including as a
system, a method, or a computer program product such as a computer readable storage medium
(including a transitory or a non-transitory computer readable storage medium) or a computer
network wherein programming instructions are communicated from a remote location.
[000115] The present invention may suitably be embodied as a computer program product
for use with the electronic device 100 and the wireless network 200. The method described
herein may be implemented as a computer program product, comprising a set of program
instructions which is executed by the electronic device 100 or any other similar device. The set
of program instructions may be a series of computer readable codes stored on a tangible medium,
such as secondary memory 106, or a computer readable storage medium, for example, diskette,
CD-ROM, ROM, flash drives or hard disk, or transmittable to the electronic device 100, via a
modem or other interface device, over either a tangible medium, including but not limited to
optical or analog communications channel(s). The implementation of the invention as a computer
program product may be in an intangible form using wireless techniques, including but not
limited to microwave, infrared, Bluetooth or other transmission techniques. These instructions
can be preloaded into a system or recorded on a storage medium such as a CD-ROM, or made
available for downloading over a network such as the Internet or a mobile telephone network.
•
The senes of computer readable instructions may embody all or part of the functionality
previously described herein.
[000116] While exemplary embodiments of the present invention are described and
illustrated herein, it will be appreciated that they are merely illustrative. It will be understood by
those skilled in the art that various modifications in form and detail may be made therein without
departing from or offending the spirit and scope of the invention as defined by the appended
claims.

•
CLAIMS
We claim,
1. An electronic device configured for sharing files with a plurality of peer
electronic devices connected to a wireless network, the electronic device comprising:
a wireless transceiver;
a primary memory;
a secondary memory; and
a processor configured to:
send from the electronic device, a request for transfer of at least one
shareable file or folder stored on a remote peer device; and
receive at the electronic device, the requested at least one shareable file or
folder from the remote peer device.
2. The electronic device of claim 1, wherein the processor is configured to precede
sending the request for transfer by one of:
sending from the electronic device, a request for listing shareable files or folders
stored on the remote peer device; or
receiving at the electronic device, a request to allow transmission of at least one
shareable file or folder stored on the remote peer device, from the remote peer device to the first
peer device.
3. The electronic device of claim 2, wherein the processor is configured to receive a
response listing shareable files or folders stored on the remote peer device, subsequent to the
sending of the request for listing shareable files or folders stored on the remote peer device.
4. The electronic device of claim 2, wherein the processor is configured to
communicate requests and responses to remote peer devices over the wireless network.
•
5. The electronic device of claim 2, wherein the processor is configured to send the
request for listing shareable files or folders to a network address of a remote peer device obtained
by the electronic device during device discovery.
6. The electronic device of claim 5, wherein device discovery IS enabled by
configuring the processor to:
send to a broadcast address of the wireless network, a handshake request
comprising a unique network address corresponding to the electronic device; and
receive from at least one remote peer device, a handshake response comprising a
unique network address corresponding to such at least one remote peer device.
7. The electronic device of claim 6, wherein the processor is configured to store
information received through handshake requests and handshake responses in a local memory,
which information enables the electronic device to identify and communicate with remote peer
devices.
8. The electronic device of claim 2, wherein the processor is configured to include in
at least one request sent to the remote peer device, a maximum chunk size which the electronic
device is capable of receiving from the remote peer device, wherein chunk size represents the
size of a discrete data unit transmitted between peer devices.
9. The electronic device of claim 10, wherein the processor is configured to receive
from the remote peer device a data file that has been broken into chunks having a size less than
or equal to the smaller of (i) the maximum chunk size which the electronic device is capable of
receiving from the remote peer device and (ii) a maximum chunk size which the remote peer
device is capable of transmitting to the electronic device.
11. The electronic device of claim 10, wherein the processor is configured to
determine maximum chunk size based on primary memory available to the electronic device.
•
12. The electronic device of claim 2, wherein the processor is configured to execute
multiple simultaneous file transfers with remote peer devices.
13. The electronic device of claim 12, wherein the processor is configured to:
add a request for transfer of at least one shareable file or folder located at a remote
peer device to a queue within the electronic device;
send the request for transfer to the remote peer device when the electronic device
has a vacant active transfer slot capable of accommodating the request for transfer;
delete the request for transfer from the queue within the electronic device,
provided the remote peer device does not have a vacant active transfer slot capable of
accommodating the request for transfer; and
receive transfer of the file or folder requested by the electronic device when both
the electronic device and remote peer device each simultaneously have a vacant active transfer
slot capable of accommodating the request for transfer.
14. The electronic device of claim 13, wherein the processor is configured to respond
to deletion of the request for transfer from the queue within the electronic device by:
receiving the request for transfer from the remote peer device, when the remote
peer device has a vacant active transfer slot capable of accommodating the request for transfer;
and
adding the request for transfer to the queue within the electronic device, provided
the first peer device does not have a vacant active transfer slot capable of accommodating the
request for transfer.
15. The electronic device of claim 14, wherein the processor is configured to respond
to deletion of the request for transfer from the queue within the remote peer device by:
sending the request for transfer to the remote peer device when the electronic
device has a vacant active transfer slot capable of accommodating the request for transfer; and
deleting the request for transfer from the queue within the electronic device,
provided the remote peer device does not have a vacant active transfer slot capable of
accommodating the request for transfer.
•
16. A method for sharing files between a plurality of electronic peer devices
connected to a wireless network, the method comprising:
sending from a first peer device, a request for transfer of at least one shareable file
or folder from a remote peer device; and
receiving at the first peer device, the requested at least one shareable file or
folder from the remote peer device.