I've seen APIs that use "*" and "::" (for IPv6) to mean "any address" (i.e. INADDR_ANY) when binding a socket. I've also seen APIs that use "" or "0.0.0.0" to mean the same. Is there a widely use standard for writing "any address" as a string?
Those are the two ways. Sadly there isn't one that works for both IPv4 and IPv6. When binding a socket you should certainly use INADDR_ANY.
It's such a good idea, that there's more than one widely used way to write that. Isn't programming fun?
Related
I’m seeing three different “error strings” for the EAFNOSUPPORT / WSAEAFNOSUPPORT errno:
POSIX:
The implementation does not support the specified address family.
BSD (errno.h, _sys_errlist[]):
Address family not supported by protocol family
Windows®/Winsock2:
An address incompatible with the requested protocol was used
While the semantics of the latter two are pretty much identical, the former differs quite a bit (it does not reference a protocol family; rather, it states that the given address family is not supported in a particular place).
I’m assuming both interpretations are valid, especially given EPFNOSUPPORT (“Protocol family not supported”) is marked as nōn-POSIX in the BSD headers, but where does this difference come from? Incidentally, my back-of-the-head/historical(FSVO) understanding of this errno code matches the POSIX semantics more than the BSD/Winsock semantics…
I can imagine that the POSIX semantic is from older BSD sockets, and later EPFNOSUPPORT was added so EAFNOSUPPORT was redesignated in BSD sockets (and Winsock just took that), or POSIX is deliberately written in a different way.
Can anyone shed light on this, perhaps explain the histories (code heritage, etc)?
I would like to describe services as components with their ports and interfaces. It should become clear by the description, what functionalities are provided, and how to utilize them.
In my understanding, I can type a port either with this notation <name>:<type>, where the type can be specified by an interface block? Or using the "lollipop", where the interface type is specified by the name of the "lollipop"?
Now, I would like to see what application or transportation protocol is utilized by a interface/port, to get an idea on how to connect to it. But I don't know what is the best way to do so. I thought about two ways.
First: specifying the protocol (here TCP/IP) by the port type and the interface (provided information) by the "lollipop" notation.
Second: specifying a transportation/application protocol as the base interface of an application specific interface.
I really don't know if any of that makes sense or if there is a better way to describe that. Please let me know.
EDIT:
Based on the answer of qwerty_so, I understand that the generalization of an interface from a protocol is wrong. But to indicate the utilized protocol, it should be specified by the port type? Based on that, I made another representation of two components (this time in UML, i hope it doesn't cause any confusion). Each component provides the same interface through a varied port. Basically it is the same as the first notation, extendet by the realize relation from the lollipop to the interface. The first component utilizes a basic TCP/IP and the second a gRPC protocol in order to realize the Interface1.
two components with different port types and same interface
Is that a more accurate way to represent the interface and its realization by a specific protocol?
Is the realize relation necessary, because shouldn't it be clear by the interface name?
TCP/IP is a protocol. And that's what is used for the port. Draw a realize relation from the port towards the interface.
The interface1 is the software interface. So draw a realize relation from the lollipop towards that.
Your lowest design would be wrong since interface and protocol are two very different things.
I always think of a port a a plug bundling a number of (SW) interfaces. In SysML terms it also extends to power supply as interface (which for pure soft-workers is kind of strange ;-).
PCI addresses adhere to the BDF notation
What would be a good way to determine if a string contains a valid PCI address?
Any programming language would do.
So I came up with the following regex (javascript) to cover the basic BDF:
^([a-fA-F0-9]{2}|[a-fA-F0-9]{4}):[a-fA-F0-9]{2}\.[a-fA-F0-9]{1,2}$
extending it to cover the extended versions of BDF should not be that hard.
I am making a project and for that i have to mention a protocol name for that.So I read about Wire Protocols used by Microsoft and Oracle, the thing is I need some names for wire protocol that i can use in postgres.
I had the same question. I would suggest the best "name" for the PostgreSQL wire protocol would be libpq, which is, of course, really just the name of the library used. I recall seeing other line protocols being called by their library APIs.
I'm doing some simple socket programming in C#. I am attempting to authenticate a user by reading the username and password from the client console, sending the credentials to the server, and returning the authentication status from the server. Basic stuff. My question is, how do I ensure that the data is in a format that both the server and client expect?
For example, here's how I read the user credentials on the client:
Console.WriteLine("Enter username: ");
string username = Console.ReadLine();
Console.WriteLine("Enter plassword: ");
string password = Console.ReadLine();
StreamWriter clientSocketWriter = new StreamWriter(new NetworkStream(clientSocket));
clientSocketWriter.WriteLine(username + ":" + password);
clientSocketWriter.Flush();
Here I am delimiting the username and password with a colon (or some other symbol) on the client side. On the server I simply split the string using ":" as the token. This works, but it seems sort of... unsafe. Shouldn't there be some sort of delimiter token that is shared between client and server so I don't have to just hard-code it in like this?
It's a similar matter for the server response. If the authentication is successful, how do I send a response back in a format that the client expects? Would I simply send a "SUCCESS" or "AuthSuccessful=True/False" string? How would I ensure the client knows what format the server sends data in (other than just hard-coding it into the client)?
I guess what I am asking is how to design and implement an application-level protocol. I realize it is sort of unique to your application, but what is the typical approach that programmers generally use? Furthermore, how do you keep the format consistent? I would really appreciate some links to articles on this matter as well.
Rather than reinvent the wheel. Why not code up an XML schema and send and receive XML "files".
Your messages will certainly be longer, but with gigabyte Ethernet and ADSL this hardly matters these days. What you do get is a protocol where all the issues of character sets, complex data structures have already been solved, plus, an embarrassing choice of tools and libraries to support and ease your development.
I highly recommend using plain ASCII text if at all possible.
It makes bugs much easier to detect and fix.
Some common, machine-readable ASCII text protocols (roughly in order of complexity):
netstring
Tab Delimited Tables
Comma Separated Values (CSV) (strings that include both commas and double-quotes are a little awkward to handle correctly)
INI file format
property list format
JSON
YAML Ain't Markup Language
XML
The world is already complicated enough, so I try to use the least-complex protocol that would work.
Sending two user-generated strings from one machine to another -- netstrings is the simplest protocol on my list that would work for that, so I would pick netstrings.
(netstrings will will work fine even if the user types in a few colons or semi-colons or double-quotes or tabs -- unlike other formats that choke on certain commonly-typed characters).
I agree that it would be nice if there existed some way to describe a protocol in a single shared file such that that both the server and the client could somehow "#include" or otherwise use that protocol.
Then when I fix a bug in the protocol, I could fix it in one place, recompile both the server and the client, and then things would Just Work -- rather than digging through a bunch of hard-wired constants on both sides.
Kind of like the way well-written C code and C++ code uses function prototypes in header files so that the code that calls the function on one side, and the function itself on the other side, can pass parameters in a way that both sides expect.
Tell me if you discover anything like that, OK?
Basically, you're looking for a standard. "The great thing about standards is that there are so many to choose from". Pick one and go with it, it's a lot easier than rolling your own. For this particular situation, look into Apache "basic" authentication, which joins the username and password and base64-encodes it, as one possibility.
I have worked with two main approaches.
First is ascii based protocol.
Ascii based protocol is usally based on a set of text commands that terminate on some defined delimiter (like a carriage return or semicolon or xml or json). If your protocol is a command based protocol where there is not a lot of data being transferred back and forth then this is the best way to go.
FIND\r
DO_SOMETHING\r
It has the advantage of being easy to read and understand because it is text based.
The disadvantage (may not be a problem but can be) is that there can be an unknown number of bytes being transferred back and forth from the client and the server. So if you need to know exactly how many bytes are being sent and received this may not be the type of protocol you want.
The other type of protocol is binary based with fixed sized messages that are sent in the header. This has the advantage of knowing exactly how much data the client is expected to receive. It also can potentially save you bandwith depending on what your sending across. Although, ascii can also save you space too, it depends on your application requirements. The disadvantage of a binary based protocol is that it is difficult to understand by just looking at it....requiring you to constantly look at documentation.
In practice, I tend to mix both strategies in protocols I have defined based on my application's requirements.