New to grpc, I just spent half an hour debugging an UNIMPLEMENTED error that seems to be a missing implementation of a method on the server-side.
But it turned out to be that the port specified (50051 as the example said) was unavailable. Switching to a different port on both server and client sides solves the problem.
However, this begs a better solution because we can't ask every rpc call to hardcode a port number. What would be the best practice?
I've consulted this question but couldn't get a sure answer for a bulletproof solution.
Thanks in advance!
Related
I've been trying to connect Freeboard to visualize context information from OCB, however came across difficulties that prevent me from receiving any data from there. My thinking is that there is a problem with connecting Freeboard to OCB, because in OCB's subscription list there are no any new entries, and datasource in Freeboard shows that it has never been updated.
OCB is turned on as a docker container. Freeboards run in docker host.
I tried setting the ip as ip that I extracted from docker by:
sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' orion1
It gave me 172.17.0.3, but on that it didn't work either. I guess it shouldn't have anyways, because I can communicate with OCB by localhost:1026 as long as I do it via cUrl or Insomnia. I can push new entities, update and so on.
The accumulation server that has not been working (link here) is ok right now. But the thing is, I add subscription by myself and can't run the acc server on localhost (loopback interface), but rather on other avaliable interface, then add ip of that interface to subscription payload that i send to OCB. Maybe there is a conflict with Freeboard somewhere.
The issue here was connected to lack of CORS support. The easy solution for this is just enabling CORS functionality while launching Orion Context Broker as described here.
I have conducted quite an (actually unnecessary) research on this topic and came up with over-the-top solution for the problem which is described in this github post. There is a proxy server approach for solving the issue. I wanted to propose adding CORS support to Orion Context Broker, and was kindly surprised when found out about it being already implemented.
There are posts like this, this and this which was very helpful in solving the case.
However, I have a two requests. I guess #fgalan is a go to person right now, regarding back-end and documentation of OCB and peripheral software.
Can there be a stronger emphasis put on CORS and ACCESS-CONTROL-ALLOW-ORIGIN soulution? The reasoning behind it is that it gives a seamless connection between OCB and any front-endy application or site (i.e. Freeboard) running in internet Browser. It shouldn't be so hidden that I came across the solution for my problems just by accident while looking for something else. I guess putting it in some walkthrough documentation on I don't know some other visible place. The problem is that I spent two weeks trying to solve it and after all went for the over-the-top and unnecessary solution while the easy and accessible was just under my nose. Good thing is that I have a good connection on stack and git so it was resolved. There are probably people that gave up on Freeboard after any slip with it. And it's a shame, because for now there is no better opensource piece of software for visualization than Freeboard. And the problem is not only with Freeboard, as I said it concerns many more front-end applications and solutions. As we go with FIWARE's way of thinking, those things should be resolved differently.
The FIWARE datasource plugin for Freeboard is not worth a dime at the moment. As #fgalan pointed out in comment it was developed for v1 version of Orion Context Broker API and has not been updated. Therefore it's way more complicated than it's suppose to be. As documentation of OCB fairly point out, v1 approach is not really RESTfull like. After conducting a short code review of OCB plugin for Freeboard I can say that's not worth using. As far as I understand it should still be working, because OCB allows for v1 request to be conducted (but it doesn't work for me anyway), those request are deprecated. In my opinion new post regarding topic should appear (not sure who should I contact about it), because this is a bit misleading. What's the point of using piece of software that's deprecated and spreading bad habits regarding interacting with OCB?
Solution for this is in my opinion simple. Just use JSON datasource in Freeboard. I understand motivation behind creating individual datasource plugin for Freeboard in 2015, when there was not RESTfull v2 version of OCB API, but there is one now, so why not use it? I used ever since got rid of difficulties with CORS and it works pretty well in my opinion. Freeboard as I said earlier provides great opportunities while being easy in setup and maintenance. It should not be abandoned so easily.
By using GET request for JSON payload in Freeboard, now we have whole access to query for context from OCB. It doesn't need any POST methods as long as we use Freeboard as it supposed to be used (by querying for data to visualize). Throw in
?options=keyValues
to the request's URL and we've gotten ourselves a really smart and compact way of visualizing data coming from the Broker.
That's just the way I thing it should be resolved. Last update on this topic coming in 2015 is just not enough in my opinion, especially if there were better methods developed on accessing context data from OCB.
I've searched this subject in stackoverflow and found out that a telnet library would help, and I found a telnet lib here: C# Telnet Library
but I don't know how I can use a telnet library to open a port in my router. I'm using an AT&T 2wire router. Any hints on how I can do this?
You can't. The 2wire router is an island unto itself, if it decides to block a port nothing external can (or should) be able to change that. You are on the wrong track, and would need to restate your goals in order to get a useful answer.
UPnP and other "Hole Punching" techniques do exist: but you'll be in a world of hurt if you try to reply on them for any widespread deployment.
Perhaps you meant to open a connection to a remote server and then establish two way communication. That is easy... and how other games and tools get the job done.
Technically speaking you should not be able to. You shouldn't have outside programatic access to a router to open a port if it's blocked.
If what you mean is opening a port for communication (that is not blocked) then you can simply create Sockets with the address and port (ex. localhost 7777) to establish inter process communication or simply communication with another server.
As I mentioned in a comment below there are ports that are available for use (in C# this can be easily tested, a quick google search will find you many snippets of code for testing if a port is open). A simple approach is to simply start at port 1024 (I believe this is the correct lower bound for ports that should be used by applications, someone correct me if I'm wrong) and just start counting up until you find a port that is available, if you find you've reached some upper limit you can simply report that a connection cannot be made. I hope this clears up a little more and if I have time I will try to find some code I have for this and edit it in but honestly a quick search can net you similar code for checking ports in C#.
Notice how I say not connecting rather than just being slow.
This has been very difficult to reproduce, I am yet to get it to happen consistently and even went to far as to move the application on to a fresh machine thinking it was hardware related but alas, new machine - same issue.
Some captures with Fiddler seems to indicate that the connection is never completed.
Any suggestions on further investigative measures?
Apologies in advance for the vagueness of the question, I am just at a loss.
Can you instrument it from the IIS side? Request tracing could tell you if something is taking so long that the request times out before it returns . . .
Are you attempting to connect via HTTPS? I've had issues in the past when trying to run on my local box and I initiate a HTTPS connection which isn't supported by cassini. When a HTTPS connection fails it's not always obvious why.
I am implementing some networking stuff in our project. It has been decided that the communication is very important and we want to do it synchronously. So the client sends something the server acknowledges.
Are there some general best practices for the interaction between the client and the server. For instance if there isn't an answer from the server should the client automatically retry? Should there be a timeout period before it retries? What happens if the acknowledgement fails? At what point do we break the connection and reconnect? Is there some material? I have done searches but nothing is really coming up.
I am looking for best practices in general. I am implementing this in c# (probably with sockets) so if there is anything .Net specific then please let me know too.
First rule of networking - you are sending messages, you are not calling functions.
If you approach networking that way, and don't pretend that you can call functions remotely or have "remote objects", you'll be fine. You never have an actual "thing" on the other side of the network connection - what you have is basically a picture of that thing.
Everything you get from the network is old data. You are never up to date. Because of this, you need to make sure that your messages carry the correct semantics - for instance, you may increment or decrement something by a value, you should not set its value to the current value plus or minus another (as the current value may change by the time your message gets there).
If both the client and the server are written in .NET/C# I would recommend WCF insted of raw sockets as it saves you a from a lot of plumbing code with serialization and deserialization, synchronization of messages etc.
That maybe doesn't really answer your question about best practices though ;-)
The first thing to do is to characterize your specific network in terms of speed, probability of lost messages, nominal and peak traffic, bottlenecks, client and server MTBF, ...
Then and only then you decide what you need for your protocol. In many cases you don't need sophisticated error-handling mechanisms and can reliably implement a service with plain UDP.
In few cases, you will need to build something much more robust in order to maintain a consistent global state among several machines connected through a network that you cannot trust.
The most important thing I found is that messages always should be stateless (read up on REST if this means nothing to you)
For example if your application monitors the number of shipments over a network do not send incremental updates (+x) but always the new total.
In a common think about network programming, I think you should learn about :
1. Socket (of course).
2. Fork and Threading.
3. Locking process (use mutex or semaphore or others).
Hope this help..
How much time would be saved in skipping the request for the IP of a domain name? Would it be noticeable. Before anyone gets to excited i know there could be problems with using an IP as opposed to a URL in web dev like if you have multiple servers, but im just curious.
Assuming they have to use the domain name to get to your site in the first place, their PC will cache the name and address, so anything you do after that won't make much difference. It's not like it does a lookup over the net for every click.
DNS resolution is cached at multiple levels. You would just be saving yourself a single roundtrip per session. Considering the hassles involved (IPs change more often than we'd like, and often not when we have control over them), I would seriously advice against it.
About the only thing it will do for you is insulate you from DNS failure. When your user experiences DNS problems, your site will be one the few that mysteriously keeps working for them!
You can still run multiple servers and load balance them behind a single IP, so that needn't be a worry. Generally though, there are far less pros than cons to this approach.
You could also add the ip and hostname to you local hosts file if you want to be save from DNS failure and slow lookups.
Although I don't think there is much merit in it, since it kind of defeats the purpose of having dns :)