william@eee-pc:~$ man nc
NC(1)
NC(1)
NAME
nc - TCP/IP swiss army knife
SYNOPSIS
nc [-options] hostname port[s] [ports] ...
nc *-l -p port* [-options] [hostname] [port]
william@eee-pc:~$ uname -a
Linux eee-pc 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u2 i686 GNU/Linux
william@eee-pc:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.8 (wheezy)
Release: 7.8
Codename: wheezy
william@eee-pc:~$ nc -l -p 5000 > /home/william/test.log
^C // no error . . .
william@eee-pc:~$
On Fri, Mar 11, 2016 at 2:31 PM, William Hermans <[email protected]> wrote:
> John,
>
> This is the first and only time I will reply to you now, or in *any*
> future post you make on any subject- period.
>
> Stop acting like a child. I'm sure that manpage might actually mean
> something on *some* Linux some where. But they mean nothing on the Linux I
> tested those commands on. I do not know if you pay attention or not, but I
> do not post commands on the groups here unless I've tested them personally,
> to prove that they work.
>
> So in the end when you pull BS stunts like you just did here you a) make
> yourself look like an idiot, and b) do the OP a disservice by confusing the
> subject. In the past, I've been playing along with your little game, but
> I'm telling you right here and now that is going to stop. I will no longer
> respond to anything you have to say on this forum in the future.
>
> On Fri, Mar 11, 2016 at 2:18 PM, John Syne <[email protected]> wrote:
>
>>
>> On Mar 11, 2016, at 10:41 AM, William Hermans <[email protected]> wrote:
>>
>> Dhanesh, netcat is pretty much a general purpose networking tool. It can
>> take stdin as input via using the pipe symbol at the command line, as well
>> as pipe that input on the opposite end to stdout.
>>
>> So as an extremely simple example:
>>
>> client side:
>> $ nc -l -p 5000 > /path/to/somefile
>>
>> From the nc MAN pages:
>>
>> *-l* Used to specify that *nc* should listen for an incoming
>> connection
>> rather than initiate a connection to a remote host. It is an
>> error to use this option in conjunction with the *-p*, *-s*,
>> or *-z*
>> options. Additionally, any timeouts specified with the *-w*
>> option
>> are ignored.
>>
>> The example in the nc MAN page:
>>
>> $ nc -l 1234
>>
>>
>> This will take input over the network from a local system attempting to
>> connect to this system via netcat on port 5000. Then of course the command
>> line redirection symbol, pipes whatever data comes in to a file.
>>
>> server side:
>> $ cat /proc/cmdline | nc 192.168.7.2 5000
>>
>> This pipes the ouput of a local system command( stdout ) to netcat, which
>> in turns sends this data to a specified IP address, and port number.
>>
>> For me, I think one of the really interesting thoughts behind this
>> process is that on the beaglebone side of things, the data could be kept
>> entirely in memory by using / creating a tmpfs file . . . size can not be
>> overly large of course. But I've personally used file sizes of 256M with no
>> ill effects. As the applications i personally ran on this test system used
>> less than 100M total for all processes. Anyway, just something to think
>> about.
>>
>> Another thing I would like to mention, in case it's not obviously to you.
>> Is that if your application can take stdin input like many std linux
>> commands. You would be able to pipe recieved data from netcat directly to
>> your application . . .
>>
>> On Fri, Mar 11, 2016 at 11:22 AM, Dhanesh Kothari <[email protected]
>> > wrote:
>>
>>> @Wally and @William, Thank you both for advice. I will study about
>>> Netcat and see how it can be used for my application.
>>>
>>> On Friday, March 11, 2016 at 11:06:56 PM UTC+5:30, William Hermans wrote:
>>>>
>>>> Something else actually just came to mind which I can not believe I did
>>>> not think of first. *Netcat* was designed specifically for this sort
>>>> of thing . . . but if you're unfamiliar with netcat, there are several good
>>>> free books on the internet I believe.
>>>>
>>>> On Fri, Mar 11, 2016 at 10:27 AM, William Hermans <[email protected]>
>>>> wrote:
>>>>
>>>>> *Thank you @Wally and @William.*
>>>>>> *My goal is to send continuous data stream from my system and my
>>>>>> beaglebone should be receiving data serially and than process the data as
>>>>>> per my algorithm without any data loss.*
>>>>>> *We are using sshfs to mount a directory on beaglebone to our system.*
>>>>>>
>>>>>
>>>>> Is sshfs your end solution then ? Or do you still want some advice ?
>>>>> If you still want more advice, then more information will be needed. We do
>>>>> not need to know exactly what you're doing, but would need to know how
>>>>> exactly you're interacting with the data. But on high level cursory look,
>>>>> I'm betting websockets *could* be made to work. Which basically means,
>>>>> your
>>>>> application development could be incredibly simple - Depending on your
>>>>> Javascript skills.
>>>>>
>>>>>
>>>>> On Fri, Mar 11, 2016 at 10:22 AM, Dhanesh Kothari <[email protected]
>>>>> > wrote:
>>>>>
>>>>>> Thank you @Wally and @William.
>>>>>> My goal is to send continuous data stream from my system and my
>>>>>> beaglebone should be receiving data serially and than process the data as
>>>>>> per my algorithm without any data loss.
>>>>>> We are using sshfs to mount a directory on beaglebone to our system.
>>>>>>
>>>>>> --
>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>> ---
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "BeagleBoard" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
