[go-nuts] schollz/peerdiscovery - Pure-Go library for cross-platform local peer discovery using UDP broadcast

[zack . scholl]

After a few hours of mild hair pulling with trying to get the pkg/net 
ReadFromUDP 
to work 
between 
Windows and Linux, I eventually just went with golang.org/x/net/ipv4 to 
write this little library that can be used for local peer discovery: 
https://github.com/schollz/peerdiscovery

I found it useful for one of my programs to perform file transfers without 
prompting for the local address. I thought I'd post it here in case anyone 
else might find it useful too.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Problem using ReadFromUDP on Windows to discover local peers

[zack . scholl]

I got it working! Got it working with golang.org/x/net/ipv4, for some 
reason the pkg/net ReadFromUDP just didn't work.

On Monday, April 23, 2018 at 12:07:07 AM UTC-7, zack@gmail.com wrote:
>
> I wrote a library (schollz/peerdiscovery 
> ) for discovering peers on a 
> local network. I've tested it between a wireless ubuntu laptop and a wired 
> ubuntu server and it works great.
>
> Basically you can run the following on computer 1 and computer 2:
>
>
> go get github.com/schollz/peerdiscovery
> cd $GOPATH/src/github.com/schollz/peerdiscovery/examples
> go run broadcast.go
>
>
> After both are run, both computers will discover each other and the 
> associated payload (in the example its a random payload), and they will 
> output something like:
>
>
> 2018/04/22 23:59:11 discovered ip '192.168.XX.XX' with payload 'YY'
>
>
> But...*this doesn't work on Windows*! I have no idea why. If one of the 
> computers is a Windows computer there is no activity, and no errors. I put 
> in logging and found that Windows will get to the ReadFromUDP(buffer) and 
> then it is unable to read anything, ever and its sent packets aren't 
> reaching the other computers.
>
> Is this a Windows firewall issue? Or something else? I'd love to hear any 
> advice, thanks! For the record, I'm using go1.10 on all computers. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Problem using ReadFromUDP on Windows to discover local peers

[zack . scholl]

I wrote a library (schollz/peerdiscovery 
) for discovering peers on a 
local network. I've tested it between a wireless ubuntu laptop and a wired 
ubuntu server and it works great.

Basically you can run the following on computer 1 and computer 2:


go get github.com/schollz/peerdiscovery
cd $GOPATH/src/github.com/schollz/peerdiscovery/examples
go run broadcast.go


After both are run, both computers will discover each other and the 
associated payload (in the example its a random payload), and they will 
output something like:


2018/04/22 23:59:11 discovered ip '192.168.XX.XX' with payload 'YY'


But...*this doesn't work on Windows*! I have no idea why. If one of the 
computers is a Windows computer there is no activity, and no errors. I put 
in logging and found that Windows will get to the ReadFromUDP(buffer) and 
then it is unable to read anything, ever and its sent packets aren't 
reaching the other computers.

Is this a Windows firewall issue? Or something else? I'd love to hear any 
advice, thanks! For the record, I'm using go1.10 on all computers. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why is there a slow-down to split one method of a struct pointer into two methods?

[Zack Scholl]

Why does it slow down the code if its not inlined? Since the method is on a 
pointer struct I assume it wouldn't need to copy anything?

I'd like to not use inlining because I need the code of this function to be 
used by two different functions and would rather not have to update the 
code twice each time its needed.

Thanks for the io.Writer idea, I'll look into that!

On Sunday, October 8, 2017 at 7:26:58 AM UTC-5, Uli Kunitz wrote:
>
> A function call per input byte will slow your code down unless the 
> function is inlined. The for loop is quite simple so I wonder why you want 
> to separate it. You should also think about whether you want to replace the 
> process method by a Write method, making your object an io.Writer and much 
> more universal.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Why is there a slow-down to split one method of a struct pointer into two methods?

[zack . scholl]

Why is it that when I a method on an struct pointer, like

func (s *Object) process(inputs []byte) {
for _, i := range inputs {
// Lots of code
}
}

it will slow down *a lot* if I move // Lots of code to its own function? 
I.e. I reorganize the above program two use two methods,

func (s *Object) process(inputs []byte) {
for _, i := range inputs {
processInput(i)
}
}

func (s *Object) processInput(i byte) {
// Lots of code
}

This new code runs 30% slower now! 

Why? 

This matters because I'm in a situation in *pluck* where I need // Lots of 
code in two places. You can reproduce this in *pluck* by running


go get -u github.com/schollz/pluck
cd $GOPATH/src/github.com/schollz/pluck/pluck
git checkout ef1004f && go test -bench=Stream -run=z
git checkout 76c4e96 && go test -bench=Stream -run=z
git diff 76c4e96 ef1004f # shows that I replace lots of code with one 
function



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is there a way to do bufio.ReadByte() starting at the end of a Reader?

[zack . scholl]

Thanks, this looks great

On Friday, August 4, 2017 at 10:34:41 AM UTC-6, rog wrote:
>
> Ah, and I just found another version, somewhat simpler, 
> that just reads bytes in reverse: 
>
> https://play.golang.org/p/mYsP7iHmiW 
>
>
> On 4 August 2017 at 16:43, roger peppe  
> wrote: 
> > I wrote this code a while ago to accomplish a similar task 
> > (actually I wanted to scan lines in reverse, but it works 
> > for bytes too, because it works with bufio.ScanBytes): 
> > 
> > https://play.golang.org/p/dqmlmdqk9k 
> > 
> > If you were going to use it in production, it would 
> > need lots of tests - it may well be wrong! Also, I've 
> > no idea what its performance characteristics are - I'm 
> > sure it would not be hard to make a reverse byte reader 
> > optimised for that purpose that was considerably 
> > more efficient. 
> > 
> > Hope this helps, 
> > 
> >   rog. 
> > 
> > 
> > On 4 August 2017 at 16:01,   wrote: 
> >> I'm working on a finite state machine that processes a file byte by 
> byte, 
> >> without loading the entire file into memory. Currently it works in the 
> >> forward direction, but I'd like to get it working in the reverse 
> direction 
> >> as well. Currently I make a *bufio.Readerfrom a open file / response 
> body 
> >> and then use ReadByte() to get each byte from beginning to end. 
> >> 
> >> 
> >> I'm wondering, what is the best way to get each byte starting from the 
> end 
> >> and going to the beginning? My first idea to read backwards is to use a 
> >> combination of UnreadByte() and Peek(1) to read in reverse after 
> advancing 
> >> the reader to the end. I'd like to avoid reading in the whole file into 
> >> memory. 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "golang-nuts" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to golang-nuts...@googlegroups.com . 
> >> For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is there a way to do bufio.ReadByte() starting at the end of a Reader?

[zack . scholl]

I'm working on a finite state machine that processes a file byte by byte, 
without loading the entire file into memory. Currently it works in the 
forward direction, but I'd like to get it working in the reverse direction 
as well. Currently I make a *bufio.Readerfrom a open file / response body 
and then use ReadByte() to get each byte from beginning to end.


I'm wondering, what is the best way to get each byte starting from the end 
and going to the beginning? My first idea to read backwards is to use a 
combination of UnreadByte() and Peek(1) to read in reverse after advancing 
the reader to the end. I'd like to avoid reading in the whole file into 
memory.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.