I follow this instruction to call smart contracts from DeBot using the message argument in the Surf URI:
https://tonlabs.notion.site/For-developers-f347bd4095f74c9d9e2bd313c666905d
It works ok, but it produces external messages. My guess is that the difference is in headers. How should I modify them to send an internal message using the same scheme?
DeBot cannot send internal message.
DeBot have 3 special features:
calling — get-methods of target smart contracts;
calling — external functions of target smart contracts onchain;
invoking — other DeBot in a local environment.
See DeBot Special Features for more details.
Yes, DeBots themselves cannot do it, so people do the following trick:
Pack debot method arguments into payload:
https://github.com/tonlabs/debots/blob/d8111db9eb5d8c42a362a0d34a4dea38f6789eec/accman/AccMan.sol#L257
Run sendTransction with the address of the current DeBot (to) and the address of a wallet (from). The wallet aka smart contract must obviously have sendTransction.
The external message is received by the wallet, and the multisig sends an internal message to the method in payload.
Once the DeBot receives this internal message, it can tunnel them to other smart contracts.
The step can be simplified, so that sendTransction is sent directly to the smart contract which requires internal message by providing the correct payload parameters (method name and params).
I think previous answers are indeed "best practice", but still incorrect. Of course, you CAN make internal messages without any additional Msig. DeBot is a smart-contract too. You just have to do the call like this:
address myDebotAddr = address(this);
IMyDebot(myDebotAddr).myFunction{...}( ... );
DeBot will call his own contract that lies in blockchain. Then in the function myFunction() you should:
have tvm.accept();
do the internal call that you need
Thus the execution of myFunction() will happen in blockchain, not locally.
Still, you will have to add funds to debot balance. So, it's not a "best practice" for widely used DeBots.
Related
For NFT minting - Standard says to emit transfer event with value of from as zero address. But i was wondering a dedicated event let's say mint sound more better and clear.
event Mint(address to, string tokenId)
Also it gives us advantage of one more variable to be indexed in event as max three value can be indexed.
Can anyone please clear this ? What is best way?
Pasted from a comment below my other answer answering a question
why not to use dedicated mint event ?
I can't speak for the authors and reviewers of the ERC-721 standard, why they chose this specific way. But from my understanding, it was already a common practice to emit Transfer event log with zero sender address when minting ERC-20 tokens, when they were creating the 721 standard. So one of the reasons might have been reusability of code for offchain apps such as blockchain explorers, to be able to handle token minting in a more generalized way.
To add context to your more specific question about the advantage of being able to pass more values:
Apart from Transfer, you can also emit other event logs, including this arbitrary Mint as well, when you're minting new tokens.
Since this Mint event is not standardized, it will not be recognized by most offchain apps (such as Etherscan) as token mint. They will only show it on the transaction detail page as "some event named Mint that we don't recognize", but their internal aggregated database of "who owns which tokens" and "these tokens were minted during this transaction" will still reflect only the values passed to the Transfer event.
However, you'll be able to handle this arbitrary event from your own offchain apps.
i have the code in solidity, i'm wondering something: I deploy code for the 0x583... first, i send 1 eth to another account. Before i click withdrawAllMoney, i click destroySmartContract, 1 eth 's automatically send to receiver (this is okie!). But after that, i keep going send the 1 eth from 0x583.. to another account, it still take out eth from 0x583.. but the orther can't receive it.
I'm wondering: when i call the selfdistruct, is the contract real deleted (can't send or recieved...)
Thank you!
when i call the selfdistruct, is the contract real deleted (can't send or recieved...)
selfdestruct() effectively removes the deployed bytecode from the contract address.
In the next block, this (former contract) address will act as a regular address without a smart contract, so it is able to receive tokens and ETH.
But, since it doesn't hold any bytecode anymore, you won't be able to interact with the contract (it's not there anymore).
As I have been able to verify, in MassTransit with Azure Service Bus, each type of object consumed by a "Consumer" generates a Topic for that type regardless of whether it is only consumed in a specific "receive endpoint" (queue). When sending a message of this type with the "Send()" method, the message is sent directly to the "receive endpoint" (queue) without going through the topic. If this same message is published with the "Publish()" method, it is published in the Topic, and is forwarded to the receive endpoint (queue) from the corresponding subscriber.
My application uses a CQRS pattern where the messages are divided into commands and events. Commands use the send-receive pattern and are therefore always dispatched in MassTransit with the "Send()" method. The events, however, are based on the publish-subscribe pattern, and therefore are always dispatched in MassTransit with the "Publish()" method. As a result, a large number of topics are created on the bus that are never used (one for each type of command), since the messages belonging to these topics are sent directly to the receiver's queue.
For all these reasons, the question I ask is whether it is possible to configure MassTransit so that it does not automatically create the topics of some types of messages consumed because they will only be sent using the "Send()" method? Does this make sense in MassTransit or is it not possible/recommended?
Thank you!
Regards
Edited 16/04/2021
After doing some testing, I edit this topic to clarify that the intention is to configure MassTransit so that it does not automatically create the topics of some types of messages consumed, all of them received on the same receive endpoint. That is, the intention is to configure (dynamically if possible, through the type of object) which types of messages consumed create a topic and which do not in the same receive endpoint. Let's imagine that we have a receive endpoint (a queue) associated with a service, and this service is capable of consuming both commands and events, since the commands are only dispatched through Send(), it is not necessary to create the topic for them, however the events that are dispatched via Publish(), they need their topic (and their subscribers) to exist in order to deliver the message and be consumed.
Thanks in advance
Yes, for a receive endpoint hosting a consumer that will only receive Sent messages, you can specify ConfigureConsumeTopology = false for that receive endpoint. You can do that via a ConsumerDefinition, or when configuring the receive endpoint directly.
UPDATE
It is also possible to disable topology configuration per message type using an attribute on the message contract:
[ConfigureConsumeTopology(false)]
public interface SomeCommand
{
}
This will prevent the topic/exchange from being created and bound to the receive endpoint.
While I can understand the desire to be "pure to the CQRS mantra" and only Send commands, I'd suggest you read this answer and take it into consideration before overburdening your developers with knowing every single endpoint in the system by name...
In wcf when i send to method which is one way-
I don't need to get answer now...
later,I need to get an answer for sure.
But how can I be sure that he got the message (to deal with it later )?
What about the 202 reponse ?
http://thejoyofcode.com/One_Way_operations_in_services.aspx
I think the article that you linked to does a nice job explaining it:
a one-way service call doesn't wait for the call to be processed, only
to be delivered - where delivery includes deserialization of the
request.
If you don’t get an exception then the message was successfully acknowledged as received.
IsOneWay introduces asynchronous aspects to your API. If you choose to go that route and you want to know what happened after the message was received, you’ll have to build that mechanism yourself. At a high level there’s nothing WCF specific about the solution. Either:
Call the service back and ask what the result was –OR–
Have the service call you back when its done
What are the essential differences between publishing a message using Bus.Publish and sending a message using Bus.Send? I am looking to understand how they differ and also when I should choose to use one over the other.
Publishing is used to notify multiple Subscribers of a particular event. A Publishing endpoint will have subscription storage to identify where to send messages to. Sending is typically used to issue a command to an endpoint. A command is telling the endpoint to do something and should not expect a reply(although you sometimes do want a reply and NSB supports this).
The reason you do not see a destination for Send() is that you specify the destination via configuration. In your app.config you will map message types(a whole assembly or a class) to a destination. When you do so, you do not have to provide the destination.
Bus.Publish: used when you don't know where the message is going (0 to many subscribers).
Bus.Send: when you are sending a message to a specific handler (client to server).
ususally Context.Publish() is for publishing Event Type and Context.Send() is for Command Type