I'm trying to run the example in this website
tutorialspoint
But it's very slow. I thought it had something to do with buffering the response but changing print for syswrite did nothing so I added some debugging messages and found out that the function gethostbyaddr takes around 10 seconds to resolve.
I know there are other modules for socket programming but I was wondering if this problem is common.
I am running everything on localhost and I am using a mac
Of course it can be slow. It contacts other machines to lookup a DNS entry. (Specifically, looking up the host name for address w.x.y.z results in a DNS lookup for the PTR record associated with z.y.x.w.in-addr.arpa.) If the authoritative DNS server is unresponsive, your machine is basically waiting for a response that will never come until your machine has decided it has waited long enough.
If you find gethostbyaddr too slow, don't use it. Just work with the IP address. It's not like gethostbyaddr is all that useful. 216.58.219.46 has names lax17s04-in-f14.1e100.net and lax17s04-in-f46.1e100.net, but you know it better as google.com. And then there's 209.85.250.97 for which gethostbyaddr returns no names, no matter how many domain names resolve to 209.85.250.97.
Related
I'm sorry if my question is too easy or obvious. I'm Comp. Science Student (it's my 6.th term).
I'm trying to combine the knowledges that I'm learning from 'Computer Networks and Security', 'Computer Organization' and 'Operating Systems' lectures in this term.
So, I cannot figure out that;
Does a computer or a phone has physical components for each 65535 ports/sockets?
Or
The machine has just one physical component. So that means port numbers are logical representations that can be shown as text-fields (like header entities or json attributes) of a request or something, to say to computer how to handle the request?
I used ports for connections of back-end and android and front-end. I know that a socket is a physical component, I worked 4 months as phone-repairer, I know these. But this makes me confused.
Thanks in advance..
Think of it this way: "the network interface is the phone system, IP-addresses are phone numbers, and socket/port numbers are like telephone extensions. (The network interface is the only physical device.)
Network traffic is carried by so-called "packets" which have various fields which tell the network how they should be routed. The IP-address will get the packet to the proper destination, then the port/socket-number will specify exactly what software process at that destination should actually handle this packet.
I need to be able to repeatably, non-randomly, uniquely identify a server host, which may be arbitrarily virtualized and over which I have no control.
A MAC address doesn't work because in some virtualized environments, network interfaces don't have hardware addresses.
Generating a state file and saving it to disk doesn't work because the virtual machine may be cloned, thus duplicating the file.
The server's SSH host keys may be a candidate. They can be cloned like a state file, but in practice they generally aren't because it's such a security problem that it's a mistake not often made.
There's also /var/lib/dbus/machine-id, but that's dependent on dbus. (Thanks Preetam).
There's a cpuid but that's apparently deprecated. (Thanks Bruno Aguirre on Twitter).
Hostname is worth considering. Many systems like Chef already require unique hostnames. (Thanks Alfie John)
I'd like the solution to persist a long time, and certainly across server reboots and software restarts. Ultimately, I also know that users of my software will deprecate a host and want to replace it with another, but keep continuity of the data associated with it, so there are reasons a UUID might be considered mutable over the long term, but I don't particularly want a host to start considering itself to be unknown and re-register itself for no reason.
Are there any alternative persistent, unique identifiers for a host?
It really depends on what is meant by "persistent". For example, two VMs can't each open the same network socket to you, so even if they are bit-level clones of each other it is possible to tell them apart.
So, all that is required is sufficient information to tell the machines apart for whatever the duration of the persistence is.
If the duration of the persistence is the length of a network connection, then you don't need any identifiers at all -- the sockets themselves are unique.
If the persistence needs to be longer -- say, for the length of a boot -- then you can regenerate UUIDs whenever the system boots. (Note that a VM that is cloned would still have to reboot, unless you're hot-copying it.)
If it needs to be longer than that -- say, indefinitely -- then you can generate a UUID identifier on boot and save it to disk, but only use this as part of the identifying information of the machine. If the virtual machine is subsequently cloned, you will know this since you will have two machines reporting the same ID from different sources -- for instance, two different network sockets, different boot times, etc. Since you can tell them apart, you have enough information to differentiate the two cloned machines, which means you can take a subsequent action that forces further differentiation, like instructing each machine to regenerate its state file.
Ultimately, if a machine is perfectly cloned, then by definition you cannot tell which one was the "real one" to begin with, only that there are now two distinguishable machines.
Implying that you can tell the difference between the "real one" and the "cloned one" means that there is some state you can use to record the difference between the two, like the timestamp of when the virtual machine itself was created, in which case you can incorporate that into the state record.
It looks like simple solutions have been ruled out.
So that could lead to complex solutions, like this protocol:
- Client sends tuple [ MAC addr, SSH public host key, sequence number ]
- If server receives this tuple as expected, server and client both increment sequence number.
- Otherwise server must determine what happened (was client cloned? did client move?), perhaps reaching a tentative conclusion and alerting a human to verify it.
I don't think there is a straight forward "use X solution" based on the info available but here are some general suggestions that might get you to a better spot.
If cloning from a "gold image" consider using some "first boot" logic to generate a unique ID. Config management systems like Chef, Puppet or Cf-engine provide some scaffolding to achieve this.
Consider a global state manager like zookeeper. Specifically its atomic counter functionality. Same system could get new ID over time, but it would be unique.
Also this stack overflow might give you some other direction. It references Twitter's approach to a similar problem.
If I understand correctly, you want a durable, globally unique identifier under these conditions:
An OS installation that can be cloned while running, so any state inside the VM won't work, and
Could be running in an arbitrary virtualization environment, so any state outside the VM won't work.
I realize this doesn't directly answer your question, but it really seems like either the design or the constraints need some substantial adjustment to accomodate a solution.
Consider the following Ladder Program that checks if a connection is enabled (A202.00) then send a message from the PLC to the PC.
The documentation (Omron CX-Programmer) has a severe lack of explanation of the program convention. What I do not understand is:
To send a message from a node to a node. I should need to specify the receiver ID. It seems the function block does not have an option where I can insert an IP address. Am I supposed to MOV an IP address to a DM address (D300) then use it? If that's the case how (IP address has dots in between 4 bytes..)?
Can someone please explain what is S (First source word), D (First destination word) and C (First control word). Aren't they just memory address? E.g. sending content of a memory adress to another memory address?
[EDIT]
What am I trying to do?
I am trying to interface a measuring gauge (controlled through Ethernet by PC/C# application) to a robotic system (no RS232 or serial, no TCP/IP, only has the simplest I/O points) with an Omron PLC. When gauge completes a measurement, the C# app sends a command to the Omron PLC which, according to the command received, switch ON or OFF an output which triggers a voltage flow to the robot's I/O port.
Should I use FINS? What functions/protocol from the PLC I need to know to do this? I do not know so I am testing every function from the documentation. So far, zero progress.
1) All addressing information is encapsulated in the five control words (C -> C+4). C- "First Control Word" is the pointer to the first word in this table of five words you must have stored somewhere in your PLC to set up the communication.
2) First source word points to the first word in your PLC you wish to send. First destination word points to the first address in the PLC/device you wish to send to. In the example , the first control word specifies that 10 words should be sent. You point to the first one and it will send that one plus the next nine addresses as well.
To do this you have to use FINS communication - the PC stores a memory structure similar to the PLCs (CIO, DM, etc) called Event Memory and these are the addresses in the PC you are pointing to. The PC gets a FINS node number and address just like a PLC would - no IP addresses are involved. (see : FINS Manual) FINS is old, however, and has been superceded by things like Sysmac Gateway.
There are much better ways of communicating between PLC/PC, however, depending on what you are trying to do. Are you trying to write an HMI? If so, what language are you using?
Edit :
If you're using C#, I highly recommend you look into Sysmac Gateway and CX-Compolet. This is probably the most flexible, simple, and extensible way to get .NET working with Omron PLCs. If it is at all possible, however, a better way might even be to have the measurement unit communicate directly with the PLC via hardware I/O (relays, DIO, etc).
CX-Compolet, Sysmac Gateway link:
http://www.ia.omron.com/product/family/63/index_l_u.html
A very generic question; in the context of a programmer, with operational aspect of the process (program) in mind.
Is there any sort of best-practice / guide to classify messages, particularly in the context of SaaS / multi-tenancy (server) software environment, which would be generating errors and warnings due to user actions or misconfiguration. Due to the nature of the software, most modules that I am having to deal with, are stateless; i.e when an error happens due to user-error, it is quite hard to distinguish between that and an operational error (like network misconfiguration, etc).
What I want to know is from some of you experienced folks; what is the sensible logic to be employed here, in order to make it easy for the operations boys/girls to classify these messages, and identify problems?
Just three aspects from an admin and log analysis/classification perspective:
Make the tag field/program name configurable. Then one can configure multiple instances to use log tags like app/user_1, app/user_2 etc., allowing for fast and simple filters on the syslog level.
Structure you messages from left to right, so one can filter different categories of log lines with simple search patterns or regular expression. E.g. config error - cannot parse line 123 or runtime warning - lost connection to DB xyz
For very structured logs you might also take a look at the 'structured data' field in syslog-protocol. So far it is rarely used and without tool support, but it allows for application log messages with namespaces and very clear key-value-attributes.
Identify the servers and server types (name, ip address, etc.)
Classify by severity, make sure all the clocks are in synch in order
to have the message ordered correctly.
Put a message/error code to filter/create some rules in your monitoring tool.
Put a module (used if several modules on one server)
Put a category for addressing general services like networking, etc.
I guess you will gather the logs from the different machines with their syslog deamon to a central machine in charge of supervision/monitoring.
Most *nix processes log to syslog (or should at least) using a semi-standard format "Month Day 24H-Time host process_name[pid]: message". Syslog incorporates ways to indicate the message's severity, use them (though keep in mind that the severity is from the system's prospective, not the applications).
If message is a debugging problem then it's usually "Function_Name File_Name Line_No Error_Code Error_Desc"; otherwise the format of the message is entirely program dependent.
For multi-tenant systems it's pretty common for the "message" part to start with some form of tenant identification, followed by the actual log message.
I've a text game I'm making to give me some practice. I'm to the point where I'm building an overhead map that just shows terrain type for where you're located in the world. The reason I ask this is because I'll be having text and BufferedImages sent to multiple clients connected to a server via socket/serversocket. Now, would it be silly to make two completely different socket connections through different ports to split up my text replies and BufferedImage replies to the various clients, or is it pretty common to decipher what an object is before deciding what to do with it when reading from an objectinputstream? Deciphering the object type would allow me to use just one serversocket connection, I just don't know how proper/practical/good practice that is. I also don't know if sending BufferedImage objects will cause a problem in receiving the text replies from the server promptly. The BufferedImage objects would be about 31x31 pixels in size, so pretty small but I'd be sending up to 9 at a time in a standard array[] type.
It's very common. In fact, I'd go as far as to say it's required, for any non-trivial remote interaction. The only question is how you want to go about communicating type information to the program on the other side of the socket connection; there are many ways of doing that, ranging from the simple (send a type-code integer first that tells the receiver what kind of data to expect next) all the way through full-blown object-serialization protocols (things like JSON, XML, Google protocol buffers, and so on).