Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sendFile and receiveFile refactoring #81

Open
viniciuscb opened this issue Mar 24, 2023 · 6 comments
Open

sendFile and receiveFile refactoring #81

viniciuscb opened this issue Mar 24, 2023 · 6 comments

Comments

@viniciuscb
Copy link
Contributor

viniciuscb commented Mar 24, 2023

Do the same refactoring as it was done with sendMessage and receiveMessage.

See:

@viniciuscb
Copy link
Contributor Author

@kirillzyusko what do you think about changing the socket listening to files to port 8989, instead of the port 8988? We are using 8988 for message already...

(of course this would break backward compatibility, as peers using old library versions could not send files to peers with new library versions....)

@kirillzyusko
Copy link
Owner

kirillzyusko commented Mar 24, 2023

@viniciuscb Well, I think it's a good suggestion!
What do you think about next approach - use 8988 for now and submit PR with this port, then create a release 3.5.0
And after 3.5.0 create 4.0.0 and introduce some breaking changes:

  • remove deprecated unsubscribe* methods;
  • use 8989 port for file transfer;
  • receiveFile/receiveMessage will always return an object containing {message/file: "", "address": ""} fields (no need to send meta as additional flag)
  • anything else?

@viniciuscb
Copy link
Contributor Author

That seems fine! By now, I have no more ideas.

@viniciuscb
Copy link
Contributor Author

I think we should update the documentation. For instance, the sendMessage() instructions in readme worked for me a bit differently.

It is not necessary anymore to create a group / be the owner of the group to send and receive messages. More than that, here in my tests (and the tests of my team) it was not possible to create a group (the android system gives me a "resource busy" message) and not even start as group owner with connectWithConfig .

It seems that a groupOwner is chosen randomly by android, but it haves some criteria: here everytime my newest mobile device was elected to be the groupOwner, the same for tests with my teammates.

@seba9999
Copy link
Contributor

seba9999 commented May 29, 2023

Hey folks !
I've been busy the last few monthes but I'm planning on trying again broadcast with RN !

@viniciuscb You're saying that it's not necessary to create a group anymore ... But how do you manage to have the "first" adress to send message then ? Which actions are mandatory to connect 3 (or more) devices and then each user could brodcast to everybody ?

Would you be kind enough to share some bootstrap code ? 😇

@kirillzyusko What about that v4 ? 🚀 Would be so nice !

I would suggest instead of message/file toggle to set data field ?

@kirillzyusko
Copy link
Owner

@seba9999 I can create v4 if needed - don't be afraid to make breaking changes, but also be sure that you know steps for migration from v3 to v4 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants