This may fix problems with very large conferences. Sadly, it seems
infeasible to test large conferences on one machine, so this is entirely
theoretical.
This allows invitations to work in the case that the invitee is already
in the group, which can happen if the group becomes split. Such an
invitation is automatically accepted, leading to the peers becoming
connected in the group and sharing peer lists.
* make static functions return bool rather than int to indicate success
* add peer_in_list() to factor out uniformity over peer and frozen lists
* reduce repetition in send_lossy_all_close
* rename 'close' to 'connections'
* use uint32_t for peernumber (in accord with tox.c)
* explain persistence in tox_conference_get_chatlist documentation
* clarify "connectedness" in group API documentation
* clarify that tox_conference_peer_count counts only online peers
* refactor variously
In windows network code, we implement inet_pton and inet_ntop, which take
void pointers. We can do slightly better because we already know the type
when we call these functions, so we can avoid casting between void
pointer and the addr struct types.
Tokstyle (check-cimple) will start enforcing comment formats at some
point. It will not support arbitrary stuff in comments, and will parse
them. The result can then be semantically analysed.
Put a future message number into the save file.
Peers require the message numbers of messages we send to increase
monotonically. If we save the current message number, then send further
messages, then quit without saving (e.g. due to a crash), and then
resume from the old save data, then monotonicity will fail. This commit
works around this problem by introducing an offset when the current
message number, so that even in the above circumstance, as long as fewer
messages than the offset were sent between saving and reloading, the
sent message numbers will increase monotonically.
The choice of offset is a balance between wanting it to be large enough
that there is room for plenty of messages to be sent in the above
scenario, and wanting to avoid the following potential problem: if we
repeatedly save and reload without sending any further messages, then
the message number may increase so far that peers will interpret an
eventual message as being old. This is not conceivably a practical issue
for the 32bit lossless message numbers, but is a concern for the 16bit
lossy message numbers.
- Moving a pthread_mutex in memory (e.g. via realloc()) is undefined
behavior.
- add a state for allocated but not yet used crypto connections
- change crypto_connection_status signature
* unset global status callback in kill_groupchats
* avoid dangling friend connections
* fix num_introducer_connections leak
* stop trying to keep connection alive on freeze
* avoid relaying lossless messages back to sender where possible
* avoid sending gratuitous online packets
Also added and used the new crypto_malloc and crypto_free.
The latter also zeroes out the memory safely. The former only exists for
symmetry (static analysis can detect asymmetric usages).
(I found I couldn't remember whether get_mono_time returned unix time or
not, and had to source-dive to find out. This should make that
unnecessary next time!)
