My assumption was that IOTA is in Java and you use java object serialization.
Could you give me a hint ;-)
Could you give me a hint ;-)
We use our own serialization, Iota works with trinary-based numbers.
Topic: IOTA - page 729. (Read 1473233 times)
Does it means, all encrypted messages become encrypted again by receiving nodes
and than sent further?
(I try to get the POW part)
and than sent further?
(I try to get the POW part)
No. Messages are retransmitted as is.
Is the POW concept explained in the paper?
OK, that implies you use bytestream <=> Object conversion by JVM.
No, JVM is not involved, it's conversion of Iota objects.
My assumption was that IOTA is in Java and you use java object serialization.
Could you give me a hint ;-)
Does it means, all encrypted messages become encrypted again by receiving nodes
and than sent further?
(I try to get the POW part)
and than sent further?
(I try to get the POW part)
No. Messages are retransmitted as is.
OK, that implies you use bytestream <=> Object conversion by JVM.
No, JVM is not involved, it's conversion of Iota objects.
Message can be encrypted or in plaintext.
All nodes send the message, not the hash.
...
Does it means, all encrypted messages become encrypted again by receiving nodes
and than sent further?
(I try to get the POW part)
...
I didn't get the serialization of a packet part - all packets are serialized objects.
OK, that implies you use bytestream <=> Object conversion by JVM.
OK, UDP seems really proper with low latency for what you are doing.
The message encryption is done by the publisher which is the POW part, right?
Than the publisher fan-out the message to all known endpoints and they store the hash only?
Do the nodes who receiving the message send them further to all endpoints they know, or the hash only?
(I guess this would be the validation process)
How do you handle serialization of all this many small packages?
Do you use protocol buffer or another queuing library?
Sorry for the many ?. But distributed apps are very fascinating (problems).
The message encryption is done by the publisher which is the POW part, right?
Than the publisher fan-out the message to all known endpoints and they store the hash only?
Do the nodes who receiving the message send them further to all endpoints they know, or the hash only?
(I guess this would be the validation process)
How do you handle serialization of all this many small packages?
Do you use protocol buffer or another queuing library?
Sorry for the many ?. But distributed apps are very fascinating (problems).
Message can be encrypted or in plaintext.
All nodes send the message, not the hash.
I didn't get the serialization of a packet part - all packets are serialized objects.
OK, UDP seems really proper with low latency for what you are doing.
The message encryption is done by the publisher which is the POW part, right?
Than the publisher fan-out the message to all known endpoints and they store the hash only?
Do the nodes who receiving the message send them further to all endpoints they know, or the hash only?
(I guess this would be the validation process)
How do you handle serialization of all this many small packages?
Do you use protocol buffer or another queuing library?
Sorry for the many ?. But distributed apps are very fascinating (problems).
The message encryption is done by the publisher which is the POW part, right?
Than the publisher fan-out the message to all known endpoints and they store the hash only?
Do the nodes who receiving the message send them further to all endpoints they know, or the hash only?
(I guess this would be the validation process)
How do you handle serialization of all this many small packages?
Do you use protocol buffer or another queuing library?
Sorry for the many ?. But distributed apps are very fascinating (problems).
Hi, may I ask some question:
How do you handle the messaging stuff?
Do you use a proprietary protocol from you Jinn software part or is it something common?
What kind of message architecture is planned (peer2peer one way pub => sub, multiplexing, ..., with middle ware)?
If the performance == message load scales well with increasing network this could be an really interesting part.
Do you expect some bottlenecks or maybe have some measurements from current tests?
How do you handle the messaging stuff?
Do you use a proprietary protocol from you Jinn software part or is it something common?
What kind of message architecture is planned (peer2peer one way pub => sub, multiplexing, ..., with middle ware)?
If the performance == message load scales well with increasing network this could be an really interesting part.
Do you expect some bottlenecks or maybe have some measurements from current tests?
We are planning to use https://en.wikipedia.org/wiki/User_Datagram_Protocol running on top of https://en.wikipedia.org/wiki/IPv6. Because of the small size of the packets https://en.wikipedia.org/wiki/Path_MTU_Discovery and https://en.wikipedia.org/wiki/IP_fragmentation are not required which simplifies networking to the max possible degree. Messages will look like transactions, they will secure the network by "paying" with PoW for their delivery to the majority of the nodes. Messages won't be preserved, only their hash will be, so the recipient will get a message only if he is online or one of the nodes decided to archive and retransmit the message after a special request which itself can be such a message.
Hi, may I ask some question:
How do you handle the messaging stuff?
Do you use a proprietary protocol from you Jinn software part or is it something common?
What kind of message architecture is planned (peer2peer one way pub => sub, multiplexing, ..., with middle ware)?
If the performance == message load scales well with increasing network this could be an really interesting part.
Do you expect some bottlenecks or maybe have some measurements from current tests?
How do you handle the messaging stuff?
Do you use a proprietary protocol from you Jinn software part or is it something common?
What kind of message architecture is planned (peer2peer one way pub => sub, multiplexing, ..., with middle ware)?
If the performance == message load scales well with increasing network this could be an really interesting part.
Do you expect some bottlenecks or maybe have some measurements from current tests?
How many full clients does the network need to support all the operation of lightweigh clients (Is there an ideal ratio between the two)?
There is no dependency.
Full client can't run on MCUs with 64 KiB RAM, but lightweight part can.
How many full clients does the network need to support all the operation of lightweigh clients (Is there an ideal ratio between the two)?
Can Itoa client be installed in most of today's sensors in term of the hardware requirement or do most of today's sensors meet the minimum hardware requirement to install Itota client?
Full client can't run on MCUs with 64 KiB RAM, but lightweight part can.
What will be the fee structure of IOTA? Or will there even be one?
There is no fees in Iota, you "pay" by securing the system.
so the sellers can price the data by per byte, or something like that, correct?
Depends. Bandwidth is too cheap for pricing per byte.
Exactly, 10^18 units is not that much if we recall share size of IoT market.
so the sellers can price the data by per byte, or something like that, correct?
even per bit :-)
Exactly, 10^18 units is not that much if we recall share size of IoT market.
so the sellers can price the data by per byte, or something like that, correct?
Jump to: